Subj : Re: posix and lock-free algorithms
To   : comp.programming.threads
From : David Schwartz
Date : Thu Aug 11 2005 10:41 pm


"David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message 
news:76UKe.2983$1i7.202@fe3.news.blueyonder.co.uk...

> Wrong. Let's look again at the precise wording:
>
>   Applications shall ensure that access to any memory location by more 
> than
>   one thread of control (threads or processes) is restricted such that no
>   thread of control can read or modify a memory location while another 
> thread
>   of control may be modifying it.

    The whole premise of this thread was that we were ignoring this 
paragraph.

> This is the relevant 'no data races' requirement on applications.

    Right, but we waived that requirement is this thread.

>   Such access is restricted using functions that synchronize thread 
> execution
>   and also synchronize memory with respect to other threads. The following
>   functions synchronize memory with respect to other threads: [blah]
>
> This is giving a way (perhaps the only way; that's not particularly clear) 
> of
> satisfying the requirement.

    No, it says the following functions synchronize memory with respect to 
other threads. That is not a means to a goal, that is a naked requirement.

> In context, it *is* clear that whatever "synchronizing memory" means, it 
> must
> mean something that can be used to avoid reading or modifying a memory 
> location
> (that is, *each* memory location that could potentially be accessed from 
> more
> than one thread) while another thread of control may be modifying it.

    No, it doesn't say "the following functions can be used to synchronize 
memory". It says the *functions themselves* synchronize memory. You are 
simply misreading it.

> But that
> doesn't have to be a global memory barrier -- because there patently are 
> other
> ways to satisfy the requirement that only involve constraints on ordering 
> of
> accesses to particular subsets of locations, not global constraints. 
> There's
> nothing here to say that a global memory barrier even has to be 
> implementable,
> or well-defined, on the target architecture.

    If you have no global memory barriers, you cannot have a function that 
"synchronizes memory with respect to other threads". POSIX requires 
functions to do this.

>> POSIX requires the mutex function to "synchronize memory". There are no 
>> caveats or warning words in this, so it *must* mean to fully synchronize 
>> all of memory.

> You're imagining things :-)

    No, you are.

>>     You cannot say "I synchronize memory because I partially synchronize 
>> some of the memory".

> Does it say "all memory"? No, it doesn't. And my interpretation is 
> supported
> by the fact that you don't need to synchronize all of memory in order to 
> meet
> the 'no data races' requirement.

    If I have three dogs and I ask my daughter to walk the dogs, can she 
walk two of them? Your straining *awfully* hard to get the standard to say 
what you want.

    It just says synchronize memory. With no caveats, that means to fully 
synchronize all of memory.

    DS

.