<JD> I also thought about "XORjoin"... but that would
help only in cases where threads execute
completely.
[MKE2] - My question is: what is wrong with having both
threads execute completely? If a <Thread> does not
execute completely, isnt everything after that "moot" at that
point anyway? The only way our testing logic
flow can been interrupted is because of an "undetermined"
cause, so how can we really continue with an xorJoin, or anything that follows that
anyway?
[Jacques Durand]
[Jacques
Durand] My only point here, is that if two threads (A and R)
are actually
started and both get their messages (which they should
not), but one fails after
that
or simply hangs while the other completes, then
XORjoin will be satisfied (in fact, XORjoin
would have to "wait" to make sure no other
thread arrives before proceeding further ! seems
unpractical).
[MIKE3] - Sounds like we need to specify
that a "system hang/ network problem" results in a
"undetermined" result for that
Thread..
and that we shoud abort the test. It does
not make sense to "continue", even if the XORJoin would allow
it
Yet we wanted to fail the test case
here, because we should NOT get both "Accept" and "Reject"
messages in the
first place. So an XORkoin would not be able to detect that, or only
in a limited set of
subcases.
[MIKE3] - Again, we can't make a rational
evaluation becase we had a "system failure".. so the Test Result
should be "undetermined". XOJoin (I believe) is a fine construc to
use, and perfect for this case. We just need to specify that
the Test Case result is "undetermined", and we exit if there is a
"timeout" on a GetMessage ( or something of that
nature).
.....
In case we don't even accept that thread R does GetMessage
successfully if A did, we need to be able to "fail" the case. I see
an Exception thread being useful here. That could be combined with
setting a "variable":
first thread to succeed doing GetMessage will set
"ResponseDone", and every thread will check this var before setting
it: if it is alrady set, that will cause
failure.
[MIKE2] - I'm confused here. I thought the point of
running a <Split> is to concurrently run independent
<Threads> ( as a useful way to optimize performance ).
But is sounds like you are saying you wish to "short circuit" the
xor logic by having concurrent <Threads> check the value of a
"flag" variable, and not finish execution if one has
already succeeded.
[Jacques
Durand] no no... I may not have expressed this clearly. Each of
the split thread (A, R) is still concurrent, but in addition, each
is setting a kind of mutex var when succeeding their GetMessage, and
each is testing this common var, so that either thread can detect if
the other also succeeded to get message. That could also be done by
a separate thread that will count GetMessage successes and "fail"
if both A and R have succeeded in doing GetMessage (even if
they hang later).
Wouldn't this
throw off the xor evaluation of the results of <Thread>s A and
R? The boolean result of <Thread>s A and R cannot both
be "true" in an xor evaluation, but we would have no way of knowing
if that may be the case because we "short circuited" the execution
of one of the <Thread>s?
/leave_workgroup.php.