Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Joe Seigh
Date : Thu Aug 25 2005 04:39 pm

Scott Meyers wrote:
> Joe Seigh wrote:
>  > No, you didn't miss anything.  Another incorrect DCL example.  Although
>  > they haven't shown the reader code or how ComputeValue handles 
> concurrent
>  > invocations.  The "ComputedValue" could be write-only for all we 
> know. :)
> 
> May I assume then that my understanding is correct that both writer and
> reader must participate in a handshake to ensure that writer changes to
> memory are visible to readers in a relaxed memory architecture?  If so,
> would it be reasonable to conclude that the semantics of the interlocked
> instructions are not generally implementable, though they may be
> implementable on particular architectures?
> 
Yes on the first part.  I'm not sure what you mean by the second part.
Can you simulate them if they're not available natively?  Yes you
can use a spin lock to guarantee atomicity and help from the kernel
(implemented as a syscall probably) to prevent the thread from preempting
while holding the lock.  The operation will be of fixed duration and
thus be "lock-free" by definition.


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.