--- In Boost-Users@y..., "terekhov" <terekhov@d...> wrote:
--- In Boost-Users@y..., "Peter Dimov" <pdimov@m...> wrote: [...]
I'm still not sure whether this is a shared_ptr problem... One might argue that the destructor of a mutable object is logically an "update" and therefore should be mutex-protected as the rest of the operations on OBJ unless it's guaranteed to not compete with them.
http://groups.google.com/groups?as_umsgid=3BCAAB99.1157302E%40web.de
"> If you need to access the object to clean it up before deleting it,
you can lock it, to make sure you have the latest value. Do not assume that just because the refcount is zero, you don't have to lock.
Yeah, that would solve the visibility problem for cleanup of mutable objects. However, with a lock protecting more than one object we could still block -- which would cause an unnecessary decrease in concurrency, increased contention. Also, the memory access reordering constrain (MBAR) injected by unlock seems to be absolutely redundant to me in this situation (and we would need unlock even in the situation with a dedicated lock per object, to ensure that lock destruction would not fail with e.g. EBUSY, AFAIK)."
On the other hand placing a memory barrier in shared_ptr will probably be a good thing from user point of view;
I think so too, but how about portability... also, given rather close to NULL amount of interest (wrt the proposal for having portable interface specifically for ref.counting) I've observed on c.p.t, I am not sure at all... maybe I am missing something subtle and the whole idea of a single "RMB" might be a BS... I do not know, really.
I don't follow this paragraph at all. Too many acronyms I can't decipher.
but I don't want to make shared_ptr depend on pthreads.
Yeah, pthreads is not a boost library, but other than that argument and perhaps some licensing issues wrt LGPL nature of pthreads-win32, I do not see why boosters just ignore pthreads. It is a standard and it is available on almost every platform out there (I mean basic threading stuff).
A) It's not available on every platform. B) It's a C library that fails to address several C++ issues. C) It has it's own issues with many of these topics, including memory visibility. A boost solution can't address all of the above concerns, but it can come closer than POSIX and helps to define what's required when a threading library is included in the C++ standard. Bill Kempf