Re: requeue with abort and timed call

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 29 Dec 2008 02:23:21 -0800 (PST), christoph.grein@eurocopter.com
wrote:

> On 28 Dez., 18:46, ishik...@arielworks.com wrote:
>> But, please think about following code.
>> Sometimes we cannot decide how long time procedures take.
>> For example, if "Procedure_Tkaes_0sec_to_60sec" takes for 0.3 or to
>> 0.0999..., Requeued_Call will be aborted.
>> but, if it takes over 1 sec, Requeued_Class will be not aborted
>> forever.
>> This behavior is repugnant, I think.
> 
> I think this is very idea behind a timed entry call - to be aborted, a
> call must be queued when the delay expires; when it executes, it will
> not be aborted.
> 
> Imagine you are waiting in a queue. If you are not serviced within a
> certain time (there is still someone before you), you leave the queue
> ("or delay", including the case that you have been partly serviced and
> are now waiting in another queue, i.e. "requeue with delay").
> 
> If you are serviced, but the service takes too long, you quit the
> service - this is the asynchronous select (the one with "then abort").

No, apart from the race condition issue, the OP has already mentioned, the
call is not serviced. Servicing was initiated by accepting the entry call,
but then it was postponed using requeue.

My understanding is that for the observer (the caller) servicing is
semantically an atomic operation which ends with the last rendzevous or
protected action. It is not abortable during a rendezvous or a protected
action, but between them it well is (unless it was requeued without abort).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de