RE: [boost] Re: Threads: Atomic Counter

From: Jeff Paquette (paquette_at_[hidden])
Date: 2000-08-31 11:47:54

at the assembly level, a 32 bit read is indeed atomic. However, I do not
believe that:

int a, b;
a = b;

is guaranteed to be atomic. Any interrupt / task switch can occur between
the fetch of b and the store to a. That is:

mov eax, [b]   ;;; pseudo x86 assembly - nits not wanted.
mov [a], eax

I would hazard a guess that InterlockedExchange disables interrupts around
the fetch and store operations. That doesn't block an NMI however, but then
again not much if anything does :)

--
Jeff Paquette
paquette at mediaone.net
http://www.atnetsend.net
> -----Original Message-----
> From: William Kempf [mailto:sirwillard_at_[hidden]]
> Sent: Thursday, August 31, 2000 12:30 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Threads: Atomic Counter
>
>
> --- In boost_at_[hidden], "Bill Wade" <bill.wade_at_s...> wrote:
> > > From: William Kempf [mailto:sirwillard_at_m...]
> >
> > > The counter is used for much more than just ref-counting.
> >
> > In general your statement is true.
> >
> > For my COW String the counter is used only for ref counting and to
> flag
> > unshareable.
> >
> > > I see no InterlockedRead.
> >
> > From developer studio help (this might be from later MSDN stuff).
> The
> > article is titled "Interlocked Variable Access" and on my machine
> has a URL
> > of
> >
> > mk:@MSITStore:M:\Disk02
> \MSDN\dllproc.chm::/devdoc/live/winbase/synchro_925v.
> > htm
> >
> > "The interlocked functions provide a simple mechanism for
> synchronizing
> > access to a variable that is shared by multiple threads. The
> threads of
> > different processes can use this mechanism if the variable is in
> shared
> > memory.  Note that SIMPLE READS and WRITES to properly-aligned 32-
> bit
> > variables are ATOMIC. The interlocked functions should be used to
> perform
> > complex operations in an atomic manner."
>
> What this seems to be indicating is that assignment of 32 bit
> integers on the Intel platform (and presumably the other platforms
> that NT works on) are atomic operations.  Quite believable to me (I'm
> not sure you can interrupt any machine level operation), but I'm not
> sure you can or should rely on this, even on the Win32 platform.
> *shrug*   Regardless, I don't *think* you'll find a performance
> difference with this and InterlockedExchange.  It surely won't be a
> 3x difference.
>
> > >I'm not referring to
> > > InterlockedExchangeAdd, but to InterlockedExchange.
> >
> > I'm not sure I know how to do a safe read with just
> InterlockedExchange.
>
> long a;
> // write
> a = 3; // according to what you posted, this is atomic
> InterlockedExchange(&a, 3);  // equivelant to above
> // read
> int b = a; // according to what you posted, this is atomic
> InterlockedExchange(&b, a);  // equivalent to above
>
> The documentation for InterlockedExchange mentions that it can be
> used for variables in shared memory between processes.  That may be
> the sole difference between InterlockedExchange and simple
> assignment... I really don't know.  All I know is that every
> article/book/etc. on this subject that I've read has recommended
> using InterlockedExchange for reading/writing.  For portability (and
> psychological safety reasons) I think exchange() is the route to go
> here, regardless of the subtle facts about the Win32 platform.
>
> Bill Kempf
>
>
>
>