<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). 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.
.....
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.