
Date: Fri, 2 Oct 2009 18:59:10 +0200 From: k-oli@gmx.de Subject: Re: [boost] [task]
Second - I'm finishing boost.task-0.4.0 which replaces this_task::reschedule_until() by this_task::block(). block() suspends the current task without blocking the worker-thread. The blocked task gets rescheduled by the internal scheduler (returning from block()):
while ( ! condition) this_task::block();
Version 0.4.0 allows to synchronize or exchange messages between the tasks without deadlocking the threadpool (that means amount of tasks >> worker- threads in pool).
regards, Oliver
Thanks - I'll steer clear of using reschedule_until at the moment. Being able to block a task without locking out the worker thread would be useful for me, but I suspect my requirement may be rather different to yours. I'm pretty much assuming amount of tasks == worker-threads in pool. My main interest in a thread pool is to avoid creating and destroying a new thread each time a task has to run but I suspect I may use task or threadpool it this way initially and see what the overhead is like. Jeremy The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html

Thanks - I'll steer clear of using reschedule_until at the moment. Being able to block a task without locking out the worker thread would be useful for me, but I suspect my requirement may be rather different to yours. I'm pretty much assuming amount of tasks == worker-threads in pool. My main interest in a thread pool is to avoid creating and destroying a new thread each time a task has to run but I suspect I may use task or threadpool it this way initially and see what the overhead is like.
with static_pool the worker-threads remains equal during the lifetime of the pool. as I explained with version 0.4.0 it doesn't matter if the amount of tasks >> worker-threads or tasks == worker etc. no threads are created or destroyed because of blocking tasks. I've povided version 0.3.0 only for convenience. regards, Oliver
participants (2)
-
Baxter Jeremy
-
k-oli@gmx.de