Subj : Re: Memory synchronization with pthreads
To   : comp.programming.threads
From : Chris Vine
Date : Mon Jan 17 2005 08:58 pm

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".

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

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.

Chris

-- 
To reply by e-mail, remove the "--nospam--" in the address

.