Re: Wording proposal for request_safe_update

Philipp, David,

It's a bummer that sc_mutex is not thread safe! But let's leave that alone...

I think we have agreed to disallow request_update and async_request_update for the same channel, right?

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.
 
Does the implementation guarantee that each call to async_request_update gets serviced separately? 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.

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?

John A

-----"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
 
[attachment "async_signal.h" removed by John Aynsley/doulos]
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.