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.