river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: TaskManager progress
Date Sat, 31 Jul 2010 10:30:30 GMT
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 <gregg@wonderly.org> 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
>
>


Mime
View raw message