Boost logo

Boost :

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-09-20 06:22:10


>Reece Dunn <msclrhd_at_[hidden]> wrote:
> Peter Dimov wrote:
> >John Maddock wrote:
> >>>I'm interested in getting something like "needs_lock" below into the
> >>>normal traits, perhaps as part of boost thread. It informs you
> >>>whether of not an operation on such a contiguous block needs a lock
> >>>to be atomic.
> >>>
> >>>For example, on ia32 32 bit aligned ops are atomic, on ia64 it is 64
> >>>bit. doubles on ia32 need locking to be atomic, on ia64 they don't.
> >>>sizeof(void*) works generically for these two platforms as is
> >>>included in the code below. A default, safety first implementation
> >>>might return true always for needs lock, or perhaps, true for all
> >>>sizeof's greater than a byte.
> >>
> >>Is it the case that we could actually rely on this? I thought for
> >>example that on IA32 operations were only atomic and thread safe when
> >>the assembly is prefixed by LOCK?
> >
> >AFAIK reads and ordinary writes are atomic without LOCK. Read-modify-write
> >operations need LOCK.
>
> The Win32 API provides InterlockedXXX for atomic operations on long data
> types, e.g. InterlockedIncrement. I am not sure about other OS's, but it
> should be possible to define an atomic_long class:
>
> class atomic_long
> {
> private: long val;
> public:
> inline atomic_long & operator++()
> {
> InterlockedIncrement( &val );
> return( *this );
> }
> // ...
> };
>
> Regards,
> Reece

Hi Reece,

As Peter pointed out, I'm just talking about atomic memory
transactions, not atomic operations in the traditional sense which is
what the interlocked ops are about.

For example, consider an object on a 486 that is 4 byte aligned. It
contains a 64 bit double and a 32 bit int. You could get and set the
int without locking, but to ensure consistency for the double you
would need to lock, set/get and unlock. On a Pentium and above with 8
byte alignment you would not have to lock either to get and set
consistently.

matt.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk