[omniORB] Some comments regarding omniThread

[Tristan Richardson]

Thanks for your comments, Bruce:

> 1. I just recently discovered that omni_mutex and omni_mutex_lock have
> compiler generated copy constructors and copy assignment operators.  I
> normally expect to see these declared private and not implemented to
> prevent them from being copied.

Yes, this is a good idea - we'll definitely do this.

> 
> 2. I think it would be useful to have protected access to the omni_mutex
> implementation.  I have recently had some problems porting NT code that
> uses omni_mutex to VMS.  The problem is that on NT an omni_mutex is
> recursive.  On VMS (DECthreads) it is not.  The result is that the
> application deadlocks on VMS.  It would be useful to be able to derive
> from omni_mutex for the purpose of initializing the mutex with a
> recursive attribute (I realize this would not be portable to other POSIX
> implementations...alas, the only portable attribute seems to be the
> default one).

Is there some reason you can't just write a recursive-safe wrapper class
around omni_mutex?

We make no guarantees about whether omni_mutex is recursive or not, because
we want mutex locking to be as fast as possible.

> 
> 3. I think the ReadersWritersLock classes (in src/appl/omniNames)
> implement a useful abstraction.  Should these be made part of
> omniThread?

Possibly, though I'm always wary of adding extra features when not absolutely
necessary.  Maybe we should make a utility library of higher-level
abstractions including this and a recursive-safe mutex?

> 
> 4. Several of the mutex related classes throw exceptions in their
> destructors.  IMHO, destructors should never throw.  In particular, it
> makes it difficult to implement a graceful shutdown of the application. 
> I will admit that the only time that I've encountered these destructors
> throwing has been when there has been another problem (which manifests
> itself via a mutex being destroyed with a lock still active).  However,
> I think it would be better if the destructor simply reported the problem
> and returned normally.

How would it "report the problem"?  We can't necessarily print out any error
messages.  Any errors occurring in these destructors are usually quite serious
- either system problems or errors in the program logic.  Ignoring the error
silently would definitely be a bad idea.  Another alternative would be to
abort, but this is even more extreme.  At least by throwing an exception you
get a chance to recover from it.  And it sounds like in your case it helped
you find the problem.


Cheers

Tristan

+--------------------------------------------------------------------+
|  Tristan Richardson                 Email:  tjr@orl.co.uk          |
|  ORL                                  Tel:  +44 1223 343000        |
|  24a Trumpington Street               Fax:  +44 1223 313542        |
|  Cambridge, CB2 1QA, UK               WWW:  http://www.orl.co.uk/  |
+--------------------------------------------------------------------+
|          ORL - The Olivetti & Oracle Research Laboratory           |
+--------------------------------------------------------------------+