Subj : Re: Memory synchronization with pthreads
To   : comp.programming.threads
From : Joseph Seigh
Date : Mon Jan 17 2005 05:35 pm

On Mon, 17 Jan 2005 20:58:29 +0000, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:

> Joseph Seigh wrote:
>
> [snip]
>
>> fork isn't a pthreads function.  It's just another syscall as far as
>> threads
>> go.  You end up with a new process with a thread running in a copy of the
>> context of the thread that called fork.  No synchronization of memory was
>> done unless you registered an at fork handler with pthread_atfork() AND
>> the handler invoked pthread functions that synchronized memory.
>>
>> Why are you going on about fork()?  It creates processes, not threads
>> except for the main thread of the process.
>
> Because I am trying to understand what you are saying.  If you look at
> section 4.10 of IEEE Std 1003.1-2001 you will see that fork() is listed
> with pthread synchronization functions where it states:
>
> "The following functions synchronize memory with respect to other threads:
> fork()
> pthread_barrier_wait()
> ..."
>
> It does not say "if you registered an at fork handler with pthread_atfork()
> AND the handler invoked pthread functions that synchronized memory".

fork shouldn't be in that list.  There's no meaningful synchronization
that fork can do by itself unless it uses pthread_atfork.  It could be
that's what they mean by including it in the list, that atfork handlers
could be registered.

>
> Presumably your view is that there are no POSIX conforming thread
> implementations?

POSIX conformance is a designation by POSIX.  It's not a matter of
anyone's opinion.

>
> A more plausible view is that what the standard in fact requires is not
> synchronization with respect to other threads, but synchronized memory as
> regards the calling thread and the new process (which is required by fork()
> anyway).  But that is not what the standard says, and in that case the
> wording of the standard is defective.
>
> I am fully aware that calling fork() in a thread reproduces the context of
> the thread that called fork() (and not also that of other threads running
> in the parent process, if any) and the consequences (namely that only
> async-signal-safe functions can be called between a call to fork() and an
> exec() in the child process created by a multi-threaded process).  That was
> not my question, nor my point.
>

The phrase "memory synchronization" is used as a catch all phrase in this
newsgroup.  What that actually entails is specific to the actual synchronization
functions.  You can't mix and match synchronization functions since the
actual synchronization you get may not be meaningful.  A lock operation
on a mutex by one thread and a semaphore operation or a lock operation on
a different mutex by another thread doesn't produce any meaningful synchronization.

-- 
Joe Seigh

.