- Forum
- General C++ Programming
- Multithreading with prime numbers
Multithreading with prime numbers
Hey guys,
I am suppose to write an application which ask the user to enter a number and the program must print out all the prime numbers less than or equal to that number. That I can handle but my main problem is that it has to be done in multithreading, Which I have been looking around for a good example and cant find one.I am using visual c++ 2008.
Please help.
Thanks in advance.
I am suppose to write an application which ask the user to enter a number and the program must print out all the prime numbers less than or equal to that number. That I can handle but my main problem is that it has to be done in multithreading, Which I have been looking around for a good example and cant find one.I am using visual c++ 2008.
Please help.
Thanks in advance.
I don't see the purpose of using multithreading in this, unless you plan for very large numbers.
You see, the idea of multiple threads require that the task can be separated in multiple work chunks. For example, examine the analogy of painting a room. You can paint it yourself alone. Let's say you paint at a rate of 1 square meter per hour. If you have 4 walls to paint, each measuring 4 x 2, then predict that you will finish in 4 x 2 x 4 = 32 hours. But what if you hire another painter? If the hired painter also paints at a rate of 1 square meter per hour, then the new predicted time is 16 hours.
This is the idea of multithreading when sought as a performance enhancement. For this to work, though, the computer must be able to physically run the two threads at once, meaning you need a dual-cored machine or better.
Multithreading is also a good option when sought as a role specialization technique. Let's use the boss-employee analogy. Let's say you painted good enough, so people start to hire you, up to the point that you find yourself interrupted by potential customers while you paint. So you decide to hire a new painter so you can stop painting and exclusively do customer-facing work. You become a bureaucrat. :-) A necessary evil. someone had to talk and deal with all these incoming customers while somebody else does the actual job of painting.
So, first you must decide multithreaded approach that you want to take: Is it performance that you are after? Or is it role-specialization?
In your case, you have a customer (the user of your program) that wants a product (all primes up to a number X). If the cost of producing the product wanted is high, and you have a dual-cored or better machine, you might want to split the job of producing the product in two hard-working threads. For example, you could have the main thread spawn two worker threads and start assigning numbers to them to determine if they are prime or not. The thread does the job and responds back to the main thread which in turn starts saving the results of these worker threads. The process continues until your product is manufactured.
Note that the above left the customer completely unattended. If the customer wanted to order more products, he couldn't because the main thread (the clerk behind the counter) went to the back to organize the workers and only came back after the product was finished.
So the performance approach just described has the problem where the customer is ignored until the task is done.
You can also multithread so you have the main thread (the clerk behind the counter) stay listening to the customer while some other guy puts the product together. This way, if the user wants more, more can be queued for processing, and if the user wants to withdraw the order, then the user can also do so before the product is finished.
So, after this long and boring explanation, I ask: What do you need to accomplish? Performance or responsiveness?
You see, the idea of multiple threads require that the task can be separated in multiple work chunks. For example, examine the analogy of painting a room. You can paint it yourself alone. Let's say you paint at a rate of 1 square meter per hour. If you have 4 walls to paint, each measuring 4 x 2, then predict that you will finish in 4 x 2 x 4 = 32 hours. But what if you hire another painter? If the hired painter also paints at a rate of 1 square meter per hour, then the new predicted time is 16 hours.
This is the idea of multithreading when sought as a performance enhancement. For this to work, though, the computer must be able to physically run the two threads at once, meaning you need a dual-cored machine or better.
Multithreading is also a good option when sought as a role specialization technique. Let's use the boss-employee analogy. Let's say you painted good enough, so people start to hire you, up to the point that you find yourself interrupted by potential customers while you paint. So you decide to hire a new painter so you can stop painting and exclusively do customer-facing work. You become a bureaucrat. :-) A necessary evil. someone had to talk and deal with all these incoming customers while somebody else does the actual job of painting.
So, first you must decide multithreaded approach that you want to take: Is it performance that you are after? Or is it role-specialization?
In your case, you have a customer (the user of your program) that wants a product (all primes up to a number X). If the cost of producing the product wanted is high, and you have a dual-cored or better machine, you might want to split the job of producing the product in two hard-working threads. For example, you could have the main thread spawn two worker threads and start assigning numbers to them to determine if they are prime or not. The thread does the job and responds back to the main thread which in turn starts saving the results of these worker threads. The process continues until your product is manufactured.
Note that the above left the customer completely unattended. If the customer wanted to order more products, he couldn't because the main thread (the clerk behind the counter) went to the back to organize the workers and only came back after the product was finished.
So the performance approach just described has the problem where the customer is ignored until the task is done.
You can also multithread so you have the main thread (the clerk behind the counter) stay listening to the customer while some other guy puts the product together. This way, if the user wants more, more can be queued for processing, and if the user wants to withdraw the order, then the user can also do so before the product is finished.
So, after this long and boring explanation, I ask: What do you need to accomplish? Performance or responsiveness?
webJose: Have you considered this may be homework?
samguddy: Here's a short example: http://www.cplusplus.com/forum/general/14470#msg70982
You'll need boost::thread. http://www.boost.org/
samguddy: Here's a short example: http://www.cplusplus.com/forum/general/14470#msg70982
You'll need boost::thread. http://www.boost.org/
Hi helios. I did. Would you say that by explaining multithreading usage I just gave away homework?
I think I just enlightened the way, which in my opinion, is the right way to help someone with his/her homework. I don't see how my explanation spoiled the homework. Or does my post compile without errors? :-)
In my opinion, giving out direct examples is more damaging to the purpose of the homework than explaining the concepts.
But I guess I could be wrong.
I think I just enlightened the way, which in my opinion, is the right way to help someone with his/her homework. I don't see how my explanation spoiled the homework. Or does my post compile without errors? :-)
In my opinion, giving out direct examples is more damaging to the purpose of the homework than explaining the concepts.
But I guess I could be wrong.
Ugh. Never mind. I didn't actually read your post, just tried to get the general gist of it, and failed.
As for whether examples are benign or malign, it depends. An example on how to test primality given to someone who needs to figure out how to test primality would obviously not be beneficial, but threading is really just interacting with libraries, particularly since there's no standard support (yet). You can either point them to the reference or provide a skeleton example. It won't make much difference, but the latter will save them an hour or two.
As for whether examples are benign or malign, it depends. An example on how to test primality given to someone who needs to figure out how to test primality would obviously not be beneficial, but threading is really just interacting with libraries, particularly since there's no standard support (yet). You can either point them to the reference or provide a skeleton example. It won't make much difference, but the latter will save them an hour or two.
Topic archived. No new replies allowed.