[omniORB] Some comments regarding omniThread

[Saroj Mahapatra]

Bruce Visscher wrote:

> I hate to reply to my own post but:
>
> Bruce Visscher wrote:
> >
> > 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, they should be private and left unimplemented.

> > 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).
> >

Recursive mutexes are not useful and best avoided in new code.

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

Yes, ReadersWritersLock is an useful class, but the current implementation
ofReadersWritersLock in omnithreads for NT is not an optimal solution. The
problem is that omni_condition walks through the list of waiters and calls
signal on an waiter-specific-semaphore (cost O(n), where n is the number of
waiters), whereas only 1 signal is needed.  So if you want to use rwlock,
barrier, or other situations where you want broadcast semantics,
omni_condition
(on NT platform) is not the best implementation.

> 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.
>

Yes, the destructor should throw only if  'exception_pending() ' (the name
could be wrong) returns false.  As most compilers do not implement this
function yet (in the C++ standard), so it is best to print out a message and
not throw exceptions in the destructor.

- Saroj Mahapatra




***********************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
***********************************************************************************