boost::threads is it all about managed threads?
I realize I might be trying to read beyond my experience level but I am having a blast and might even be getting somewhere learning a new programming style, a little. :) So, I've been looking at boost::threads and pthreads while considering a problem. I was never a believer in threads, I come from an SMP background and always found that for what I wanted to do, async IO beat the pants off threads. Not that I want to start a war, just that I want to explain why I'm happy with concurrent programming but a complete nonce case when discussing thread programming. I have an application in mind for comparison and it's not particularly complex but it's a monster in LOC, mainly due to the liberal use of FORTRAN in whatever language the compiler happens to take. But one of the things it does have, that I'd rather not re-implement, is a request service library. That library picks up an incoming request, goes and carries out the action and then returns the result. The requests are of unbounded duration and there are multiple clients so the service times are pretty sad. I think that sounds like a job for threads; no need to alter the service code, just replace the routine that returns the results and bob's your mum's brother and I can get 10 at a time all sleeping waiting for the requested IO. But to not scare the natives I'd prefer to have a single thread unless the load actually demands more. Now, my old C brain can see that the main thread can get it's thread ID from thread_self() and then just be one of the guys but I can't see how the boost::thread() can do anything but give me threads to manage. After stepping on myself with a vectorboost::thread :) I think this is the tao of boost::thread: const boost::function0<void> run = &go; boost::thread_group grp; for(int i = 0; i < 100; i++) { grp.create_thread(go); } grp.join_all(); Is that right? What am I missing? How do I get a bunch of peer boost::threads? If you're still with me thanks very much for your time and help and let me know if I'm dragging the list off topic and I'll go find someone else to bug. -- Blue Skies
Dear Mr. Moderator,
I realize I have been a PITA over the last few days but on the off
chance it's that there's a mail snafu rather than a moderation
decision, can you confirm that you do, as your first aut response
said, give a positive acknowledgement for declined posts? Or has that
policy changed because of the weight of traffic?
If I've crossed a line it might be quicker to let me know so I can go
find another place to post questions.
Thanks for your time, I appreciate the function you provide in the list.
Anthony Booker.
---------- Forwarded message ----------
From: The Grumpiest Man You Know
I realize I have been a PITA over the last few days but on the off chance it's that there's a mail snafu rather than a moderation decision, can you confirm that you do, as your first aut response said, give a positive acknowledgement for declined posts? Or has that policy changed because of the weight of traffic?
If I've crossed a line it might be quicker to let me know so I can go find another place to post questions.
Thanks for your time, I appreciate the function you provide in the list.
Rejected posts are always acknowledged, and you'll usually get a reason as well (don't post in HTML, don't post large attachments etc). However: 1) If your messages are in a moderation queue (and they may well be as a new member) then depending upon time zones and which moderators are online etc, it may take half a day or so before the message is seen and moderated. 2) If you post via the gmane newsgroup then there is a delay before gmane passes the messages on to the list. 3) If the list server is busy, or your ISP is busy there may be a delay before the message travels through the list and back to your mailbox, I've seen delays of up to 3 or 4 hours for my own messages to get back to me (via the list). John.
Rejected posts are always acknowledged, and you'll usually get a reason as well (don't post in HTML, don't post large attachments etc).
However:
1) If your messages are in a moderation queue (and they may well be as a new member) then depending upon time zones and which moderators are online etc, it may take half a day or so before the message is seen and moderated.
2) If you post via the gmane newsgroup then there is a delay before gmane passes the messages on to the list.
3) If the list server is busy, or your ISP is busy there may be a delay before the message travels through the list and back to your mailbox, I've seen delays of up to 3 or 4 hours for my own messages to get back to me (via the list).
John.
Thanks very much for the response Mr. Maddock, I guess I'll have to keep looking for my problem. I was concerned when it seemed to be a day or two of silence. Since you didn't tell me to bog off I'll just keep hanging round and earwigging then. :) Apologies if gmail is sending HTML, I'll go look to turn that off.
On Thu, 3 Mar 2005 23:19:52 -0800, The Grumpiest Man You Know
I think that sounds like a job for threads; no need to alter the service code, just replace the routine that returns the results and bob's your mum's brother and I can get 10 at a time all sleeping waiting for the requested IO. But to not scare the natives I'd prefer to have a single thread unless the load actually demands more.
Now, my old C brain can see that the main thread can get it's thread ID from thread_self() and then just be one of the guys but I can't see how the boost::thread() can do anything but give me threads to manage. After stepping on myself with a vectorboost::thread :) I think this is the tao of boost::thread:
const boost::function0<void> run = &go; boost::thread_group grp;
for(int i = 0; i < 100; i++) { grp.create_thread(go); }
grp.join_all();
Is that right? What am I missing? How do I get a bunch of peer boost::threads?
This looks fine to me. I'd just suggest as a general design not stopping and starting threads with any great frequency (which is what you seem to suggest at the end of the first quoted para). Leave your threads running all the time, but use some sort of synchronized queue to pass them work to process (and perhaps a second queue to get results back). If all threads are busy the requests will start to back up in the queue, but when the queue is empty, all of the threads will block waiting for data, and this will use very little in the way of system resources. -- Caleb Epstein caleb dot epstein at gmail dot com
participants (3)
-
Caleb Epstein -
John Maddock -
The Grumpiest Man You Know