RE: Pthreads-w32 project still alive?

["Bossom, John" <John.Bossom@Cognos.COM>]

For a portable solution for cross process synchronization you could use
a file lock an a well known file.
You could use this a sort of a cross process "mutex".

FYI... I noticed that the RealTime spec for semaphores support "named"
semaphores... If so then you could pass the buck back to the developer
to remember the "name" and therefore not require a list... (however, I
am unfamiliar with the RealTime library - is it always there?)

Cheers
John E. Bossom (still lurking deep in the background)
 

-----Original Message-----
From: pthreads-win32-owner@sourceware.org
[mailto:pthreads-win32-owner@sourceware.org] On Behalf Of Ross Johnson
Sent: Wednesday, November 01, 2006 10:14 PM
To: Gianlucaspm@hotmail.com
Cc: pthreads-win32@sources.redhat.com
Subject: Re: Pthreads-w32 project still alive?

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 ( (   )  )
>  (___)   (___)
 
     This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you.