Hi Patricia,
I haven't completed the second round of tests yet, these should be
complete by morning. I don't think it's safe to assume absence of
failure precludes it.
We can see the potential for failure, we just haven't simulated the
conditions for it I suspect.
You should be able to run the qa tests yourself with ant qa.run, we
should probably look at how we can run some simulations using the qa suite.
Cheers,
Peter.
Patricia Shanahan wrote:
On Jul 30, 2010, at 13:50, Gregg Wonderly <[email protected]> wrote:
Patricia Shanahan wrote:
Gregg Wonderly wrote:
In the case of task manager, it helps asynchronous activity
happening on separate threads, understand how to manage data races
such that outcomes can be predictable no matter how scheduling occurs.
Here is where I disagree. TaskManager itself is not sequence-number
aware. Suppose T1 and T2 are two tasks with sequence numbers 1 and 2
respectively. T1 and T2 are of the same type, and their runAfter method
would consider them a match in everything it tests except for sequence
number.
T2 will return true for a runAfter test on a list containing only
T1. T1
will return false for a runAfter test on a list containing only T2,
because of the sequence number test. Both return false on an empty
list.
If they are always added to a TaskManager in the order T1 then T2, the
sequence number check is unnecessary. If a task appears in the runAfter
check collection and conflicts with the current task, it has a lower
sequence number than the current task.
The interesting case is T2 added before T1. Suppose the TaskManager is
empty and has a couple of waiting threads at the time T2 is added. T2
sees an empty runAfter check list, so it is immediately runnable and
the
thread is notified. The TaskManager thread may have committed to
running
T2 before T1 is added.
Is there a case that you can point at, where T2 is added before T1?
I am not aware of such a case with my casual knowledge of this part
of the code.
I also don't know of any case. The test patch I've uploaded
effectively asserts their is no such case, a hypothesis that needs to
be examined every possible way.
The highest risk, as I mentioned,is RetryTask. T1and T2 could be in
order initially, but T1's first attempt fails and it is added again,
after a delay, as a retry.
Also,in some cases all that is really needed is mutual exclusion,
which could be achieved by getting rid of thr sequence number test.
A control paradigm where explicit knowledge of your dependencies is
expressed in the APIs for dispatching tasks seems like the needed
change.
Maybe. The first issue to resolve is whether the RetryTask users
really need order, or just mutual exclusion.
Patricia
