Subj : Re: Memory synchronization with pthreads
To   : comp.programming.threads
From : Joseph Seigh
Date : Sun Jan 16 2005 05:59 pm

On Sun, 16 Jan 2005 22:01:36 +0000, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:

> Joseph Seigh wrote:
>
>> On Sun, 16 Jan 2005 19:51:38 +0000, Chris Vine wrote:
>>
>>> Section 4.10 of IEEE Std 1003.1-2001 provides that a number of specified
>>> functions, such as pthread_mutex_lock(), pthread_mutex_trylock(),
>>> pthread_mutex_unlock(), sem_post() and sem_wait() "synchronize memory
>>> with respect to other threads".
>>>
>>> For a process with multiple threads does this imply that a call in a
>>> thread which, say, locks or unlocks a mutex will synchronise memory with
>>> respect to only the other threads in the process holding (or trying to
>>> hold) a lock on the mutex, or does it require all threads in the process
>>> to have memory synchronized, whether or not they are waiting on the mutex
>>> and indeed whether or not they have access to the mutex?
>>>
>>
>> Only with respect to other threads using the same mutex or semaphore as
>> far as you will be able to reliably and deterministically observe.
>>
>> Most memory models require memory to be synchronized on both reading as
>> well
>> as writing memory.  So the impression you have that one thread can
>> synchronize memory for all other threads without the need for any action
>> by those threads isn't the case for most platforms.
>
> Thanks.
>
> fork() is one of the functions required to synchronize memory.  Presumably
> that must synchronize memory for all threads in the process in which one of
> the threads has fork()ed (otherwise it is difficult to see what the
> standard thinks it requires on a fork)?

AFAIK, it doesn't.

>
> This also has implications for the question in this newsgroup under the
> subject line "Memory visibility and synchronization using pipes".  It would
> be nice to translate your "most likely it is safe" in that case into a
> "required to be safe" - I was wondering whether one of the threads making a
> (otherwise meaningless) call to sem_post() to a (otherwise unnecessary)
> semaphore in one of the threads would do this without the other thread
> having to do anything special.  Perhaps a (otherwise meaningless) fork()
> would do this?
>

The phrase "synchronize memory" isn't defined in Posix pthreads.  You need
to learn more about memory models and memory consistency and how it's
accomplished before you attempt to do memory synchronization outside of the
standard thread design patterns and paradigms.  You should learn what memory
barriers are and how to use them.  Also why context switching from a syscall
or thread switch needs to synchronize memory.


-- 
Joe Seigh

.