[Freepooma-devel] Reviewing thread-safety

[Richard Guenther]

Hi!

In reviewing thread-safety of f.i. Unique or the RefCounted stuff
I have seen several flaws in the design.  It is more or less trivial
to fix these, but as a prerequesite I'd like to know if thread-safety
has been tested thoroughly at all?

To quote one example, there is no point in having Unique::get()
and Unique::lockedGet(), as both need to ensure thread-safety - in
fact, all but ObserverEvent use the non-thread-safe ::get() variant,
which is broken.

Another example is the RefCounted class which exposes f.i.

inline bool
RefCounted::isShared() const
{
  mutex_m.lock();
  bool test = count_m > 1;
  mutex_m.unlock();
  return test;
}

nice try - but there is no value in the return value after
the unlock() - instead a caller to isShared needs to ensure
proper locking around whatever it is trying to do.  Similar
errors are spread around RefCountedPtr and friends.

Of course all these are notoriously inefficient if ever something
else than the noop mutex comes into play.  Using (and implementing)
atomic operations on integers would be a way to go.

Is it worth fixing all of the above at all?

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/