Subj : Re: C++ desired features
To   : (Usenet)
From : Hans Boehm
Date : Wed Feb 23 2005 07:23 pm

Sergey P. Derevyago wrote:

> 	Sure, we need some synchronization primitives (such as mutexes) to
implement
> inter-thread communication. As a rule, thoroughly designed MT
application is a
> set of fully independent threads which communicate via the message
queues. The
> synchronization primitives are used inside these queues and virtually
no locks
> are supposed outside the queues.
If that's possible, great.  For the problems I've dealt with, the
problems usually aren't quite independent.  And destructors especially
tend to involve shared data structures, since their job is typically to
return something to a shared resource pool.  You can sometimes keep the
resource pools per thread, but that incurs other substantial risks.

> 	But what we see in real life is herds of mutexes spread across the
code.
> "MT-aware classes" try to lock almost every method...
I agree that's usually a bad idea.  Synchronization should be left to
the client  unless the library introduces shared data that's not
visible to the client.

> And even more, some
> "industrial-strength" PLs have the built-in mutex per every object!
IMHO there
> is no excuse for this madness.
If you're talking about the Java approach, then the cost of associating
a lock with each object is actually pretty small.  It may be a few bits
per object, or a table off to the side.  Overusing those locks is of
course not cheap.

Hans


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

.