RE: [OpenSTA-devel] Re: Platform SDK

[Wickersham, P. <Pet...@di...>]

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.

thanks,
peter

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Mark
Elam
Sent: Thursday, January 19, 2006 3:22 PM
To: ope...@li...
Subject: Re: [OpenSTA-devel] Re: Platform SDK

Daniel Sutcliffe wrote:
> Peter Wickersham wrote:
>=20
>>I'm testing my random patch in the next day or so.  The only issue
>>that I am not clear on is whether or not I need to guard the calls
>>into the MTRand class (Mersenne Twister Random).  It is not
>>threadsafe, but is this a major issue?  I am not sure if we are
>>guarded upstream of these calls due to the use of MUTEX statements
>>in the SCL and other possible mutexes.  Anyone know this?
>=20
>=20
> It's a good question and one I, unfortunately, don't know the answer
> to.  The fact that Mark was concerned about the lack of controlled
> atomicity to the srand(),rand() pair would suggest to me that you do
> need to be somewhat concerned - Mark would have more idea than most
> as one of the original coders of this area.


I'll try and have a look at the weekend but if memory serves...

Using a MUTEX around your GENERATE and NEXT statements in SCL should
have the desired effect of 'protecting' the random variable, assuming,
of course, that the MTRand class is entirely contained as a member of
the CECVar derived class. However, I believe that the original purpose
of having the MUTEX and SEMAPHORE statements was more to do with
allowing synchronisation across virtual users for the purposes of
atomicity on multiple SCL statements and avoiding data race between
unrelated scripts, rather than the simple 'guarding' outlined above.

Certainly, if this is the case, it could be argued that we should allow
the use of variables to be thread safe without the need for extra SCL
statements. I do not believe that this is currently, explicitly, true.=20
However, the internal workings of the threading model used and the=20
mechanisms of CORBA used for the GLOBAL variables may mean that this=20
does not cause a problem for most situations.

The threading, in particular, has changed since I wrote the variable=20
code, and the CORBA variable handling has been moved to within the=20
Daemon process rather than the old TestManager Process(where it was=20
guaranteed that CORBA variable objects would be destroyed at the end of=20
a test). But I think the actual variable handling is still pretty much=20
the same.

In short I would say, I think that thread-safety is an issue, but that=20
it may be difficult to prove :-)

Mark






-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
_______________________________________________
OpenSTA-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensta-devel