Re: Wording proposal for request_safe_update

I agree with Phillipp's points.

On Wed, Dec 1, 2010 at 5:01 PM, Philipp A. Hartmann <
philipp.hartmann@offis.de> wrote:

> John,
>
> please find my opinions below.
>
> On 01/12/10 20:30, john.aynsley@doulos.com wrote:
> [snip]
>
> > I think we have agreed to disallow request_update and
> async_request_update for the same channel, right?
>
> Fine for me, if "disallow" means "undefined behaviour".
>
> > Re. processing async_request_update, I have some questions.
> >
> > There can be no guarantee that a call to async_request_update gets
> > serviced at all, right? It could just be "too slow" and only "reach the
> > kernel" after the end of simulation.
>
> Yes. But this is fine, I guess. Especially with the proposed feature
> to keep the simulation time at the point of starvation. You could then
> simply restart the simulation after the async_request_update (since the
> sim may just be paused).
>
> > Does the implementation guarantee that each call to async_request_update
> gets serviced separately?
>
> I'd say: no. It shall guarantee, that the kernel internals are sane,
> even for arbitrarily many competing calls from different threads. No
> further synchronisation semantics.
>
> All request_update calls (external or not) are serviced by a single
> update() call in the following update phase. Whatever "following" means
> is decided by the kernel for external calls.
>
> > What if a second async_request_update comes in while there is still
> > a call pending? With request_update, update() would only get called once.
>
> For symmetry reasons, it should be the same for async_request_update.
>
> > Now your question. If you have async_request_update() and update() in
> parallel, it seems to me there are two possible outcomes:
> >
> > 1. Treated as two parallel async_request_update calls for the same
> channel, in which case only one update gets queued
> >
> > 2. The async_request_update() effectively slips to the next delta cycle,
> resulting in two separate calls to update. (What if there were 3 or 4
> pending calls? 3 or 4 delta cycles?)
> >
> > I think either outcome is legal, and the choice is non-deterministic. It
> comes back to the question of whether the implementation is obliged to
> service every async_request_update separately, or whether calls can be
> collapsed to a single update(). Or have I interpreted things wrongly?
>
> You're right on this. As said above, I would prefer to collapse
> multiple calls to async_request_update(), so there should be either 1 or
> 2 calls to update(), not 3 or more.
>
> This issue can be seen as a race between the channel "external" member
> function calling async_request_update() and the kernel calling update().
> So it may just be a quality-of-implementation issue, that this does not
> lead to a deadlock by choosing one of your 2 options. I'm fine with
> leaving the exact choice unspecified in the LRM.
>
> Greetings from Oldenburg,
> Philipp
>
> DELETED OLDER THREAD

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.