New shared pointer - revision 2

[Mirko Boehm]

On Saturday 10 September 2005 19:18, Koos Vriezen wrote:
> Just curious, what is the cost of making this thread-safe? I'm asking
> this because I wonder how often this will be used in such a way.
>
> I'm always a bit sceptic when it comes to MT, IMO MT programs should
> only exchange data between threads in critical sections. Other than
> avoiding races, I can't really think of a real benefit as well. So one can
> access a pointer thread safe, and then what, the pointer itself is not
> thread safe. Oh wait, poll for a value to set by another thread? Come
> on, we have pthread_cond_wait or pthread_join to do that much more
> efficient.
This is true, but shared pointers are a special case as the reference 
increments and decrements are not controled by the programmer. It is not easy 
to encapsulate those in critical sections. 
 
As long as we use the Qt classes, the reference counting is thread-safe at 
very limited cost. If we implement our own, we face the same issues the 
Trolls did.

What you describe is a general requirement for mt programming. Smart classes 
just make it harder to keep control. 

--Mirko.
-- 
KDE e.V.: http://www.kde.org/areas/kde-ev/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050910/88d94647/attachment.sig>