Re: Garbage Collection - The Trash Begins To Pile Up
Andreas Huber wrote:
Peter Dimov wrote:
mv.lock; // protects v
int x = v;
f();
assert( x == v );
mv.unlock;
With an appropriate amount of C, X and getFoo, I can make the above
demonstrate that the problem exists with GC as well. :-)
I don't understand. What problem exists with GC as well? Surely not that
synchronous finalization fails under certain circumstances?
The problem with recursive locks leading to data integrity problems.
This of course has nothing to do with synchronous finalization. The
problem is that the code above depends on the mutex mv to protect the
variable v, and it assumes that since it's holding a lock on mv, v does
not change. Recursive mutexes break this assumption. If f indirectly
starts calling another piece of code that modifies v, also under
protection of mv, this will lead to silent and subtle failures as the
assumption x == v is violated. A non-recursive mutex will deadlock, not
allowing this to happen.
Another unfortunate Java design decision is that it encourages
method-level locking, which can lead people to believe that the
granularity of their locks is not a vital property of the design, both
in terms of correctness and performance. :-)
All this does not invalidate Hans Boehm's point, of course. It's
unquestionably better to invoke finalizers from a thread that holds no
user-visible locks, especially if client code cannot predict the
specific moment in which a finalizer will be invoked by the system. I'm
just saying that by following good locking practices, you can avoid the
problem (and likely increase performance) when using shared_ptr.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]