|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-12 11:51:39
From: "Saul Tamari" <saul_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> > From: "bill_kempf" <williamkempf_at_[hidden]>
> ...
> > > 1) Spin locks, by themselves, are prone to memory visibility issues.
> > >
> > > 2) Spin locks use "busy waits" and thus chew up CPU resources while
> > > trying to acquire the lock. Unless the lock contention is low this
> > > overhead can quickly become detrimental to the performance of the
> > > application.
> >
> > Actually (1) is rarely an issue, since the atomic instructions used to
> > implement a spinlock usually act as memory barriers.
>
> What instructions? The actual assembly for test-and-set is also a memory
> barrier?
Sometimes.
> Or an equivalent function that also calls a memory barrier?
Yes, usually the atomic function is documented to act as a memory barrier.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk