Re: [OT]Re: atomic flag

From: Jeff Schwab (jeffplus_at_comcast.net)
Date: 01/15/04 

Date: Thu, 15 Jan 2004 05:30:44 -0500

Nick Hounsome wrote:
> "Jeff Schwab" <jeffplus@comcast.net> wrote in message
> news:R7Wdnca8e_HIcpjdRVn-jw@comcast.com...
>
>>Ron Natalie wrote:
>>
>>>"Jeff Schwab" <jeffplus@comcast.net> wrote in message
>
> news:27idncgNDfwefZjdRVn-uQ@comcast.com...
>
>>>>Peter Koch Larsen wrote:
>>>>
>>>>
>>>>>"Jeff Schwab" <jeffplus@comcast.net> skrev i en meddelelse
>>>>>news:886dnfBKB6Y_y5nd4p2dnA@comcast.com...
>>>>>
>>>>>
>>>>>
>>>>>>Shayan wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Is there a boolean flag that can be set atomically without needing to
>>>>>>>wrap it in a mutex? This flag will be checked constantly by multiple
>>>>>>>threads so I don't really want to deal with the overhead of mutexes
>
> or
>
>>>>>>>semaphores. Thanks.
>>>>>>
>>>>>>
>>>>>>I believe setting a flag /is/ an atomic action. It's when you want to
>>>>>>bundle multiple operations as an atom that problems may occur
>>>>>>
>>>>>
>>>>>You are wrong - at least on systems with multiple processors.
>>>>
>>>>No, I'm not. The machines I use most have from two to fourteen
>>>>processors. All the processors on a given machine share some memory.
>>>>
>>>
>>>
>>>That doesn't say anything about automic operations.
>>
>>Yes, it does. The memory -- the place where the datum is stored -- is
>>shared among the processors. A write is atomic.
>>
>>
>>>More is involved then
>>>just sharing memory. Do these things have cache? It's extremely rare
>
> to
>
>>>see a machine the memory itself is synchronized (the HEP was unique in
>>>this regard).
>>
>>Keeping the cache in sync with the memory is done at a much lower level.
>> It's the concern of the hardware & the OS.
>>
>
>
> I'm with Ron on this one:
> The memory can't be kept totally in sync in the way that I think is being
> discussed here -
> think about it - it would hammer performance.

That's why caching is used.

> The OS helps but only at certain points which means that you have to use
> things like mutexes for memory shared between
> processors. The locking and unlocking of the mutexes consitute 'memory
> barriers'
> Locking the mutex throws out cached reads so that you get any new stuff in
> the memory.
> Unlocking the mutex flushes out cached writes.
> Obviously it is possible to have an machine code instruction that does the
> whole lot - that is how mutexes in shared memory are written.

How do you think mutexes work? They rely on the fact that a write is
atomic. Keep in mind that the OP was not asking about a read after
write ("RAW"), only a single write.

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... However, if you were to uncomment the line that sets x to 3, thread 2 ... don't see how I could more directly illustrate Rule, ... understand the 4 rules which were phrased in terms of mutexes and condition ... by in pthreads having never heard of a memory barrier or cache consistency. ...
    (microsoft.public.vc.mfc)
  • Re: [OT]Re: atomic flag
    ... > Ron Natalie wrote: ... > Keeping the cache in sync with the memory is done at a much lower level. ... The locking and unlocking of the mutexes consitute 'memory ... volatile bool* flag; ...
    (comp.lang.cpp)
  • Re: WaitForSingleObject() will not deadlock
    ... memory fence, too. ... Not as fast as a pthreads semaphore, ... A kernel mutex also takes care of priority ... Uncontested mutexes are extremely ...
    (microsoft.public.vc.mfc)
  • Re: phreads and processes
    ... It appears that in a single process, if two pthreads ask for the same shared ... memory with the same key, the first thread gets the memory, and the ... >> instead of mutexes, if I wanted to. ... > using pthreads there is usually no need to use semaphores, ...
    (comp.unix.programmer)
  • Re: [ANN] Mongrel 0.3.13.4 Pre-Release -- Rubys LEAK Fixed (Death To Mutex!)
    ... its memory more quickly than without, ... `sync; sync; sync` ... It is "standard software engineering practice" in any environment ...
    (comp.lang.ruby)