Re: [boost] [threads] Win32 Events on POSIX

Subject: Re: [boost] [threads] Win32 Events on POSIX
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-02-16 05:56:06

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/