Jacques,
Another option ( if there is a
chance of "synchronization problems" if 2 or more concurrent Threads are
trying to read/set a parameter (e.g. mutex="true") would be to run
all of those Threads "serially". Then, when one Thread is "elected", it
sets mutex="true", and all subsequent serial Threads read that value and
simply <Return>.
Otherwise, we have to
come up with a "locking" scheme for a parameter when it is accessed by a
Thread, which implies a database-type mechanism to perform the lock and
release.
[Jacques
Durand] there are some simple semaphor programming techniques that would
prevent race conditions - I also believe that Java threads handle that
natively?
We could still
permit multiple concurrent Threads to modify a global parameter, but results
could be shaky if one or more of those Threads read/set that value.
[Jacques
Durand] multiple read is OK, and set can be taken care of even
natively by Java threads. We don't have to make this feature "core" for
conformance to TestFramework, if not. But that should not stop us to specify
it.
Comments?
Mike