Re: [boost] Re: Smart pointers: One more implementation +question

From: Pavel Vasiliev (pavel_at_[hidden])
Date: 2003-02-06 09:46:28

Alexander Terekhov wrote:

>>
>> "Pavel Vasiliev" <pavel_at_[hidden]> wrote in message
>> news:1111364312.20030205192141_at_mpen.bas-net.by...
>> > [...]
>> > 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