Re: [OpenSTA-devel] Re: Platform SDK
Brought to you by:
dansut
|
From: Mark E. <ma...@bo...> - 2006-01-24 21:47:59
|
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 |