[drmaa-wg] Simultaneous waits on the same job id?

[Peter Troeger]

> Ed,
>
> What Andreas is trying to get at is that since synchronize()  
> doesn't return job information, so multiple simultaneous synchronize 
> () calls will all succeed.  Even if synchronize() reaps job info,  
> since other calls to synchronize() don't care whether they actually  
> are able to find the job info, it's all good.  As long as  
> synchronize() is running, reaped jobs are viewed as simply having  
> ended, so not even a call to wait() will cause a call to synchronize 
> () to fail.
>
> Is that really correct?  Can anyone else confirm?  I think we  
> should probably have a tracker to clarify that point in the (g2) spec.

I confirm. The DRMAA group agreed (in another discussion) that sync()  
has call-time context semantics. The text from the spec says more or  
less the same. Therefore, your synchronize call should succeed if  
jobs 5,6,7 existed at the time when thread 2 invokes the operation.

Peter.

>
> Daniel
>
> Andreas.Haas at Sun.COM wrote:
>> On Fri, 23 Jun 2006, Ed Baskerville wrote:
>>
>>> OK, I'll do that. But one more question: how do these issues  
>>> apply to synchronize? Consider the following sequence:
>>>
>>> thread 1: wait(job id 5)
>>> thread 2: synchronize(job ids 5,6,7)
>>> [job id 5 finishes]
>>> ¿thread 2 synchronize call fails?
>>> [job id 7 finishes]
>>> [job id 6 finishes]
>>> ¿thread 2 synchronize call succeeds?
>>>
>>> Should synchronize fail with INVALID_JOB as soon as any of the  
>>> ids it's waiting on are reaped? Or should it eventually succeed?
>>
>> There is no reason for synchronize to fail, as long as none of the  
>> jobs was reaped when synchronize() gets issued.
>>
>> Andreas
>