Re: Wording proposal for request_safe_update

David, Philipp,

Then we all agree! I have written this up.

John A

-----David C Black <dcblack@xtreme-eda.com> wrote: -----
To: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
From: David C Black <dcblack@xtreme-eda.com>
Date: 12/02/2010 04:34AM
Cc: john.aynsley@doulos.com, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: 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.