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 original sketch. regards, alexander. P.S. When are you going to kick start an incarnation for Itanic with value dependent cmpxchg.rel-vs-cmpxchg.acq? ;-)