Re: Pthreads-w32 project still alive?

[Ross Johnson <rpj at callisto dot canberra dot edu dot au>]

Gianlucaspm@hotmail.com wrote: 
> Is the project still alive?
> If so, is there any planning for the pthreads implementation of process
> synchronization primitives?
Hi Gianluca,

The project is not dead, but dormant, in that it is in a working stable 
state. There have been no critical bugs reported since 2.7.0 and the 
project has almost fulfilled it's original intended scope (as much as is 
practical at least) of implementing the Threads section of the POSIX API.

Process Shared primitives have been sitting in the "hard" basket since 
the start of the project. At first glance it looks as if all we need to 
do is call the appropriate Win32 "named" sync routines, but I believe 
this is not the way to go for the following reasons. First, we would 
need to manage the internal lists of [random] names and guarantee that 
they won't ever conflict with names in an application, and there are 
other issues with Win32 named objects (security etc). Second, real 
pthreads implementations use shared memory in combination with process 
shared sync primitives, and that means, for source level portability, we 
would need to implement enough of the POSIX shared memory API anyway 
even if we did use these named objects. I have a feeling there would be 
other undesirable side effects if pthreads-win32 doesn't use a similar 
implementation.

So my preference if implemented in pthreads-win32 is for fully 
shared-memory sync primitives and, with that in mind, I had been 
gradually trying to deal with the third and final issue - to redefine 
pthreads-win32 sync primitives (at least those that should be process 
shared) as a prerequisite to be properly memory sharable. Various code 
rewrites and ideas from several contributors over time to improve speed, 
reliability and behaviour etc. has gotten us much closer to that 
situation, with more use of Interlocked instructions replacing Win32 
kernel calls. That is where we are in 2.7.0, which is working well if 
the absence of bug reports is any indication.

POSIX threads primitives that are candidates for process sharing are:
Semaphores
Mutexes
Condition Variables
Read/Write Locks

IIRC, the semaphore implementation is totally Interlocked based now. 
Mutexes are based on Interlocked instructions and pthreads semaphores, 
so they too are potentially sharable. Condition Variables are based on 
pthreads semaphores and pthreads mutexes, and finally, Read/Write Locks 
are based on pthreads semaphores, mutexes, and condition variables.

Success here would also mean that message queues could be implemented to 
work between processes. There is contributed code (in the contrib area I 
think) that fully implements shared MQs but in pthreads-win32 they work 
only within the same process. This code has never been merged into the 
library because of this - because I didn't want to have to deal with 
reports about MQs not working etc.

Having said that, I haven't had the time, resources or commitment lately 
to initiate new work on the project, and there have been very few, if 
any, requests for this feature in particular to motivate progress.

Ideas, suggestions and contributions are welcome though.

Regards.
Ross

>  
> Thanks a lot for your past (and I hope future) work,
> Gianluca
>  
>         () ()
>       ( 0 0 )
>      ( =:.:= )
>       (     )
>      ( (   )  )
>      ( (   )  )
>   o ( (   )  )
>  (___)   (___)