Re: Wording proposal for request_safe_update

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

> -----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
> To: john.aynsley@doulos.com
> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> Date: 11/29/2010 09:40PM
> Cc: David Black <dcblack@xtreme-eda.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
> Subject: Re: Wording proposal for request_safe_update
>
> John, David,
>
> On 29/11/10 12:37, john.aynsley@doulos.com wrote:
>>
>> Yes, we are on the same page. If we do include async_request_update in the
>> LRM then I think we need to spell out the recommended usage carefully,
>> otherwise users are going to make mistakes. Should we give an example
>> using an sc_mutex to protect a member m_new_value, perhaps?
>
> I agree, that a some documentation how to use this would be very
> helpful. Unfortunately, an sc_mutex won't help since it is not (OS)
> thread-safe either.
>
> I think, a full example might add too much platform-specific noise to
> the LRM. We could of course add a straight-forward example that hides
> the platform details behind some interface (see attached).
>
> On the other hand, there are still quite a lot of issues, that need to
> be carefully considered when doing parallel programming. We can't
> possibly discuss all those pitfalls in the LRM.
>
> Lastly, I think the wording could be improved regarding the interaction
> between update() and async_request_update().
>
> An implementation should guarantee, that for a given channel
> async_request_update() can be called (and succeed) _in parallel_ to the
> call of update() of that very same channel during the update phase.
> Otherwise, you can easily run into deadlocks (e.g. in the attached
> example).
>
> There has been a NOTE proposed by David. I'm not sure, if this
> expresses this issue clearly enough (since any application-defined locks
> are not covered), quote:
>
> NOTE 3 - Due to the asynchronous nature of calls to
> *request_safe_update*, it is necessary that code
> implementing the update phase must take care when handling
> updates from the set of safe update requests. It is possible
> for a request_safe_update call to be made at anytime from
> start of simulation including during the update phase.
>
> Opinions?
>
> Greetings from Oldenburg,
> Philipp
>
> [snipped previous discussion to avoid bouncing]
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.