On 16 Feb 2015 at 11:58, Andrey Semashev wrote:
On Monday 16 February 2015 08:30:58 Fu ji wrote:
Thank you for the reply. I see that you have almost all functionality done, I miss only something equivalent to WaitForMultipleObjects it is in your plans for the future functionality ?
On POSIX systems this is only achievable with select() & co., which in turn implies that synchronization primitives must be fd-based. I currently have no plans for implementing that, mostly because I recon that such primitives would have worse performance in the normal use (i.e. when a single primitive is used for thread synchronization).
You can implement an entirely user space wait_for_all and wait_for_any easily enough. Indeed, one of the things myself and Vicente discusssed for the mooted Boost.Thread v5 rewrite was to move thread scheduling completely into user space whereby the sole and only way of kernel sleeping a thread (apart from i/o) is a thread locally stored condvar. Thread v5 would keep a registry of threads and their thread local condvars, and would wake a thread when needed. With regards to the OP, he may find my C11 permit object of use as that does allow wait composure and works on all platforms, including Windows. See https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Permit% 20Test%20Linux%20GCC%204.8/lastSuccessfulBuild/artifact/latex/pthread_ permit_reference.pdf specifically the API pthread_permit_select(). The OP should note that pthread_permit_select() is not particularly efficient as it does not allocate memory. I am unaware of an algorithm which permits O(1) waiter complexity and does not require dynamic memory allocation. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/