From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2005-04-04 03:18:21
Peter Dimov wrote:
> If you are interested, please take a look at the file
Looks correct, but sill not quite optimal to my taste.
A) There's no need to hinder compiler's ability to cache/reorder
across increments. So you need neither __volatile__ nor "memory"
clobber in increments case (lock prefix is still needed to ensure
MP safety of competing read-modify-write operations).
B) Something branchless is better for unconditional increments.
C) In the case of decrements on weak_count, there's no need to
make all clients pay the price of rather expensive interlocked
operation even if they don't use weak pointers. I'd use "may
not store zero" decrement. You'll need __volatile__ and "memory"
as compiler fence, and as for hardware, that initial load does
have acquire semantics and lock cmpxchg does have "msync::hsb"
which we need here.
> thanks to Alexander Terekhov
Thanks to you for helping me to identify the problem with lock()
(lack of inter-thread ordering with respect to that access and
destruction of control block when the object is expired) in my
P.S. When are you going to kick start an incarnation for Itanic
with value dependent cmpxchg.rel-vs-cmpxchg.acq? ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk