atomic flag

[Shayan]

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.

Shayan

[Jeff Schwab]

Re: atomic flag

Shayan wrote:[color=blue]
> 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.[/color]


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

[Ron Natalie]

Re: atomic flag


"Shayan" <ssarkar@harris .com> wrote in message news:699af6ab.0 401131230.50858 e34@posting.goo gle.com...[color=blue]
> 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.[/color]

There's no concept of atomicity in general. C has a sig_atomic_t
type, but even that only applies to signal handling.

[Nick Hounsome]

Re: atomic flag


"Shayan" <ssarkar@harris .com> wrote in message
news:699af6ab.0 401131230.50858 e34@posting.goo gle.com...[color=blue]
> 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.
>
> Shayan[/color]

1. No there isn't.
2. There is no simple mechanism even in assembler that will do this
correctly on a MP system.
3. In my experience waiting on a condition/semaphore can be faster than busy
waiting.

[Peter Koch Larsen]

[OT]Re: atomic flag


"Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
news:886dnfBKB6 Y_y5nd4p2dnA@co mcast.com...[color=blue]
> Shayan wrote:[color=green]
> > 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.[/color]
>
>
> 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
>[/color]
You are wrong - at least on systems with multiple processors.

/Peter

[Richard Head]

Re: [OT]Re: atomic flag

On Wed, 14 Jan 2004 11:28:01 +0100, Peter Koch Larsen wrote:
[color=blue]
>
> "Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
> news:886dnfBKB6 Y_y5nd4p2dnA@co mcast.com...[color=green]
>> Shayan wrote:[color=darkred]
>> > 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.[/color]
>>
>>
>> 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
>>[/color]
> You are wrong - at least on systems with multiple processors.
>
> /Peter[/color]

Not true Oh wise one. Some machine architectures have special
'interlocked' machine instructions of the sort TSTI, INCI, DECI,
etc which are garanteed to use a single bus transaction regardless
of how many processors (i.e. read/write without freeing the bus).
Some other machines use interlocked transactions by default and
others no such instructions. But if the processor can be used in
a multiprocessor then there is defintely some feature that
supports these functions which can be accessed by assembly and
maybe by your compiler.

You will have to examine the machine language for the particular
architecture. If you find such instructions then you need to
test to see if your compiler will generate such instruction or
use the asm directive.

[Peter Koch Larsen]

Re: [OT]Re: atomic flag


"Richard Head" <rh90p@comcast. net> skrev i en meddelelse
news:pan.2004.0 1.14.11.15.07.4 62006@comcast.n et...[color=blue]
> On Wed, 14 Jan 2004 11:28:01 +0100, Peter Koch Larsen wrote:
>[color=green]
> >
> > "Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
> > news:886dnfBKB6 Y_y5nd4p2dnA@co mcast.com...[color=darkred]
> >> 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[/color][/color][/color]
or[color=blue][color=green][color=darkred]
> >> > 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
> >>[/color]
> > You are wrong - at least on systems with multiple processors.
> >
> > /Peter[/color]
>
> Not true Oh wise one. Some machine architectures have special
> 'interlocked' machine instructions of the sort TSTI, INCI, DECI,
> etc which are garanteed to use a single bus transaction regardless
> of how many processors (i.e. read/write without freeing the bus).
> Some other machines use interlocked transactions by default and
> others no such instructions. But if the processor can be used in
> a multiprocessor then there is defintely some feature that
> supports these functions which can be accessed by assembly and
> maybe by your compiler.
>
> You will have to examine the machine language for the particular
> architecture. If you find such instructions then you need to
> test to see if your compiler will generate such instruction or
> use the asm directive.
>[/color]
And how do you do that in C++?

/Peter

[Jeff Schwab]

Re: [OT]Re: atomic flag

Peter Koch Larsen wrote:[color=blue]
> "Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
> news:886dnfBKB6 Y_y5nd4p2dnA@co mcast.com...
>[color=green]
>>Shayan wrote:
>>[color=darkred]
>>>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.[/color]
>>
>>
>>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
>>[/color]
>
> You are wrong - at least on systems with multiple processors.[/color]

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.

[Ron Natalie]

Re: [OT]Re: atomic flag


"Jeff Schwab" <jeffplus@comca st.net> wrote in message news:27idncgNDf wefZjdRVn-uQ@comcast.com. ..[color=blue]
> Peter Koch Larsen wrote:[color=green]
> > "Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
> > news:886dnfBKB6 Y_y5nd4p2dnA@co mcast.com...
> >[color=darkred]
> >>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
> >>[/color]
> >
> > You are wrong - at least on systems with multiple processors.[/color]
>
> 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.
>[/color]

That doesn't say anything about automic operations. 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).

[Jeff Schwab]

Re: [OT]Re: atomic flag

Ron Natalie wrote:[color=blue]
> "Jeff Schwab" <jeffplus@comca st.net> wrote in message news:27idncgNDf wefZjdRVn-uQ@comcast.com. ..
>[color=green]
>>Peter Koch Larsen wrote:
>>[color=darkred]
>>>"Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
>>>news:886dnfB KB6Y_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.[/color]
>>
>>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.
>>[/color]
>
>
> That doesn't say anything about automic operations.[/color]

Yes, it does. The memory -- the place where the datum is stored -- is
shared among the processors. A write is atomic.
[color=blue]
> 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).[/color]

Keeping the cache in sync with the memory is done at a much lower level.
It's the concern of the hardware & the OS.

[Nick Hounsome]

Re: [OT]Re: atomic flag


"Jeff Schwab" <jeffplus@comca st.net> wrote in message
news:R7Wdnca8e_ HIcpjdRVn-jw@comcast.com. ..[color=blue]
> Ron Natalie wrote:[color=green]
> > "Jeff Schwab" <jeffplus@comca st.net> wrote in message[/color][/color]
news:27idncgNDf wefZjdRVn-uQ@comcast.com. ..[color=blue][color=green]
> >[color=darkred]
> >>Peter Koch Larsen wrote:
> >>
> >>>"Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
> >>>news:886dnfB KB6Y_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[/color][/color][/color]
or[color=blue][color=green][color=darkred]
> >>>>>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.
> >>[/color]
> >
> >
> > That doesn't say anything about automic operations.[/color]
>
> Yes, it does. The memory -- the place where the datum is stored -- is
> shared among the processors. A write is atomic.
>[color=green]
> > More is involved then
> > just sharing memory. Do these things have cache? It's extremely rare[/color][/color]
to[color=blue][color=green]
> > see a machine the memory itself is synchronized (the HEP was unique in
> > this regard).[/color]
>
> Keeping the cache in sync with the memory is done at a much lower level.
> It's the concern of the hardware & the OS.
>[/color]

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

Anyway the original poster seemed to want:

volatile bool* flag;

while(flag)
;
flag = true;

This is unlikely to work even on a single processor machine.

Getting back to C++ - I think I read somewhere that there is a clash between
C++ and the POSIX threads decls but
I have never had any problems.

[Jeff Schwab]

Re: [OT]Re: atomic flag

Nick Hounsome wrote:[color=blue]
> "Jeff Schwab" <jeffplus@comca st.net> wrote in message
> news:R7Wdnca8e_ HIcpjdRVn-jw@comcast.com. ..
>[color=green]
>>Ron Natalie wrote:
>>[color=darkred]
>>>"Jeff Schwab" <jeffplus@comca st.net> wrote in message[/color][/color]
>
> news:27idncgNDf wefZjdRVn-uQ@comcast.com. ..
>[color=green][color=darkred]
>>>>Peter Koch Larsen wrote:
>>>>
>>>>
>>>>>"Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
>>>>>news:886dn fBKB6Y_y5nd4p2d nA@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
>>>>>>>thread s so I don't really want to deal with the overhead of mutexes[/color][/color]
>
> or
>[color=green][color=darkred]
>>>>>>>semaphor es. 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
>>>>processor s. All the processors on a given machine share some memory.
>>>>
>>>
>>>
>>>That doesn't say anything about automic operations.[/color]
>>
>>Yes, it does. The memory -- the place where the datum is stored -- is
>>shared among the processors. A write is atomic.
>>
>>[color=darkred]
>>>More is involved then
>>>just sharing memory. Do these things have cache? It's extremely rare[/color][/color]
>
> to
>[color=green][color=darkred]
>>>see a machine the memory itself is synchronized (the HEP was unique in
>>>this regard).[/color]
>>
>>Keeping the cache in sync with the memory is done at a much lower level.
>> It's the concern of the hardware & the OS.
>>[/color]
>
>
> 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.[/color]

That's why caching is used.
[color=blue]
> 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.[/color]

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.

[Peter Koch Larsen]

Re: [OT]Re: atomic flag


"Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
news:VeOdnVFMuu Zj9pvdRVn-hA@comcast.com. ..[color=blue]
> Nick Hounsome wrote:[color=green]
> > "Jeff Schwab" <jeffplus@comca st.net> wrote in message
> > news:R7Wdnca8e_ HIcpjdRVn-jw@comcast.com. ..
> >[color=darkred]
> >>Ron Natalie wrote:
> >>
> >>>"Jeff Schwab" <jeffplus@comca st.net> wrote in message[/color]
> >
> > news:27idncgNDf wefZjdRVn-uQ@comcast.com. ..
> >[color=darkred]
> >>>>Peter Koch Larsen wrote:
> >>>>
> >>>>
> >>>>>"Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
> >>>>>news:886dn fBKB6Y_y5nd4p2d nA@comcast.com. ..
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Shayan wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Is there a boolean flag that can be set atomically without needing[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> >>>>>>>wrap it in a mutex? This flag will be checked constantly by[/color][/color][/color]
multiple[color=blue][color=green][color=darkred]
> >>>>>>>thread s so I don't really want to deal with the overhead of mutexes[/color]
> >
> > or
> >[color=darkred]
> >>>>>>>semaphor es. Thanks.
> >>>>>>
> >>>>>>
> >>>>>>I believe setting a flag /is/ an atomic action. It's when you want[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> >>>>>>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
> >>>>processor s. 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[/color]
> >
> > to
> >[color=darkred]
> >>>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.
> >>[/color]
> >
> >
> > I'm with Ron on this one:
> > The memory can't be kept totally in sync in the way that I think is[/color][/color]
being[color=blue][color=green]
> > discussed here -
> > think about it - it would hammer performance.[/color]
>
> That's why caching is used.
>[color=green]
> > 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[/color][/color]
in[color=blue][color=green]
> > the memory.
> > Unlocking the mutex flushes out cached writes.
> > Obviously it is possible to have an machine code instruction that does[/color][/color]
the[color=blue][color=green]
> > whole lot - that is how mutexes in shared memory are written.[/color]
>
> 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.
>
>
>[/color]

Mutexes work because they use specialpurpose instructions - on the intel
cpu's using the "lock"-prefix. You can not do that in (portable) C++.

Kind regards
Peter

[Jeff Schwab]

Re: [OT]Re: atomic flag

Peter Koch Larsen wrote:[color=blue]
> "Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
> news:VeOdnVFMuu Zj9pvdRVn-hA@comcast.com. ..
>[color=green]
>>Nick Hounsome wrote:
>>[color=darkred]
>>>"Jeff Schwab" <jeffplus@comca st.net> wrote in message
>>>news:R7Wdnca 8e_HIcpjdRVn-jw@comcast.com. ..
>>>
>>>
>>>>Ron Natalie wrote:
>>>>
>>>>
>>>>>"Jeff Schwab" <jeffplus@comca st.net> wrote in message
>>>
>>>news:27idncg NDfwefZjdRVn-uQ@comcast.com. ..
>>>
>>>
>>>>>>Peter Koch Larsen wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>"Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
>>>>>>>news:886 dnfBKB6Y_y5nd4p 2dnA@comcast.co m...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Shaya n wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Is there a boolean flag that can be set atomically without needing[/color][/color]
>
> to
>[color=green][color=darkred]
>>>>>>>>>wrap it in a mutex? This flag will be checked constantly by[/color][/color]
>
> multiple
>[color=green][color=darkred]
>>>>>>>>>thread s so I don't really want to deal with the overhead of mutexes
>>>
>>>or
>>>
>>>
>>>>>>>>>semaph ores. Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>>I believe setting a flag /is/ an atomic action. It's when you want[/color][/color]
>
> to
>[color=green][color=darkred]
>>>>>>>>bundl e 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
>>>>>>processor s. 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[/color][/color]
>
> being
>[color=green][color=darkred]
>>>discussed here -
>>>think about it - it would hammer performance.[/color]
>>
>>That's why caching is used.
>>
>>[color=darkred]
>>>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[/color][/color]
>
> in
>[color=green][color=darkred]
>>>the memory.
>>>Unlocking the mutex flushes out cached writes.
>>>Obviously it is possible to have an machine code instruction that does[/color][/color]
>
> the
>[color=green][color=darkred]
>>>whole lot - that is how mutexes in shared memory are written.[/color]
>>
>>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.
>>
>>
>>[/color]
>
>
> Mutexes work because they use specialpurpose instructions - on the intel
> cpu's using the "lock"-prefix. You can not do that in (portable) C++.[/color]

Mutexes can be provided without any such instructions. It might
interest you to look at some of the many-splendored implementations of
the "wait" and "signal" semaphore functions. At any rate, you don't
need a mutex to make a write atomic, unless you're implementing a cache
and are using "write" to mean "input to cache."

And as far as portable C++ goes, a write certainly is atomic, since the
standard provides no support for multiple simultaneous threads of
execution. Beyond that, I don't believe I've ever seen a system where a
write was not an atomic operation. In fact, if thread 1 writes
succesfully to a variable, and thread 2 immediately reads from the same
variable and sees anything other than the value written by thread 1,
then thread 2 is not accessing the same variable. A write is atomic by
definition. If you don't believe so, then we mean different things by
"write."

[Peter Koch Larsen]

Re: [OT]Re: atomic flag


"Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
news:7LCdnZSpk-gYTpvdRVn-ug@comcast.com. ..[color=blue]
> Peter Koch Larsen wrote:[color=green]
> > "Jeff Schwab" <jeffplus@comca st.net> skrev i en meddelelse
> > news:VeOdnVFMuu Zj9pvdRVn-hA@comcast.com. ..
> >[/color][/color]

[snip]
[color=blue][color=green]
> >
> >
> > Mutexes work because they use specialpurpose instructions - on the intel
> > cpu's using the "lock"-prefix. You can not do that in (portable) C++.[/color]
>
> Mutexes can be provided without any such instructions. It might
> interest you to look at some of the many-splendored implementations of
> the "wait" and "signal" semaphore functions. At any rate, you don't
> need a mutex to make a write atomic, unless you're implementing a cache
> and are using "write" to mean "input to cache."
>
> And as far as portable C++ goes, a write certainly is atomic, since the
> standard provides no support for multiple simultaneous threads of
> execution.[/color]

Standard C++ has no notion of threads (yet), but this does not mean that you
can't call portable C++ code from a multi-threading program.
[color=blue]
> Beyond that, I don't believe I've ever seen a system where a
> write was not an atomic operation. In fact, if thread 1 writes
> succesfully to a variable, and thread 2 immediately reads from the same
> variable and sees anything other than the value written by thread 1,
> then thread 2 is not accessing the same variable. A write is atomic by
> definition. If you don't believe so, then we mean different things by
> "write."
>[/color]

I am sorry, but you are simply plain wrong. But do not take my word for it -
go to comp.programmin g.threads and study some of the many threads discussing
this very issue.

/Peter