Re: [OpenSTA-devel] Re: Platform SDK

[Mark E. <ma...@bo...>]

Wickersham, Peter wrote:
> Well, I would totally agree that the underlying system should be
> threadsafe without any regard to the SCL statements used. It shouldn't
> be required for the script writer to be concerned about those details.
> 
> That said, I am still barely scratching the surface of all the
> foundation classes that are in use in OpenSTA. So, is there already an
> abstraction of a mutex into a base class to be used for this purpose. I
> believe that I have seen some in looking through the code, but it would
> be helpful if I had a direct pointer on which class to use. I haven't
> had a lot of time to dig into the code to figure out which Projects
> (libraries) are base libraries for all the different executables in the
> system.

There's probably about 3 abstractions of a mutex in various shapes and
forms, including those that come with OmniORB (omni_mutex_lock) and a 
CLock from FastLock.hpp , there's also a CTMutex in the CyrToolsOS 
Project :-)

However, having looked a bit further the file TContext.cpp uses a lock
in TContext::set_variable and TContext::get_variable which I believe is
where all the calls for setting and retrieving values for variables
during script reply is handled (A TContext instance used to represent , 
for all intents and purposes, a thread context/virtual user). On closer 
inspection this lock is a member of TContext so probably wouldn't do 
much, maybe this should be made static? This seems a little overkill for 
within a single process (only one variable can be set/got at a time) but 
would seem to provide the protection required.

This does not hold true for CORBA based variables in a multi test-engine
scenario though. Here it is possible to have 2 or more processes try and
use the same variable simultaneously and I can't see any locking
mechanism. The workings of CORBA/OmniORB may mean that it is unlikely
(or even impossible) that two calls would be 'brokered' in this way but
I can't remember if this can be guaranteed, I can't even remember if I
ever knew if this was guaranteed :-)

If we wanted to make sure then GlabalVariableImpl::get_value and 
set_value etc. could probably be locked, but I think this would add 
extra locking for the 'normal' situation mentioned above as well. 
Personally I would rather be sure that locking was required before it 
was added but...

On an aside I suppose it would be nice to move towards just one 
abstraction of mutexes and other useful classes. Certainly if OpenSTA 
moved away from using the OmniORB thread classes etc I believe it would 
be possible to make the code work for different ORBs (how are MICO and 
TAO doing these days?).

Mark