Alexander Terekhov wrote: >> >> "Pavel Vasiliev" <[EMAIL PROTECTED]> wrote in message >> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> > [...] >> > In my implementation of refc_ptr operator= performs >> > incrementing/decrementing within a single guarded section (since >> > the only global instance of interl. op. mutex is used for all > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > cases). So the copying via operator= is about twice faster in my >> > implementation.
> Really? What about contention? Well, it's a nice way to play > ping-pong on a multiprocessor system... or am I just missing > and/or misunderstanding something? Ok, I expected this question just from you, Alexander :-). Much of my thread safety knowledge is adjusted by your postings and links that you provided in them. I really think that having the only mutex for all short smart pointer-related interlocked operations will not harm performance of real-life applications in mp systems. In my code this mutex is used only for really short operations like "lock, increment, save to temporary, unlock, test the temporary". It is hard to imagine that contention will often occur for so short operations. Though the problem may be with contention while in a system-level code for locking/unlocking. The time it takes may be large enough. But to my knowledge (please correct me if I misunderstand something) usually no matter which exactly mutex is being locked/unlocked - all CPUs must wait due to hardware issues. But even if I am wrong, slight performance loses due to contension seem (to me) to be not important compared to the resources saved (only one mutex instead of a new one for each allocated object. Spinlock is not always available). > It's probably a bit more exciting to take care of all possible races > without "a true lock" protecting both counters. I'm not sure that the > true locking is *necessary* to support weak references. Do you have > an illustration, Pavel? Alexander, I can not currently add more to the discussions concerning weak references support. I mean that I have the same issues as Peter Dimov with shared_ptr/weak_ptr. My implementation differs but the problem is much the same: "test and conditionally increment". I would be very interested to learn about a portable way to protect both counters with only one interlocked operation. But if it takes two or more interl. ops., then the spinlock mutex does the things better. Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
