Re: Wording proposal for request_safe_update

Philipp, David,

Philip wrote "I think, we can allow both as long as they result in a
_single_ call to 'update' in the corresponding update phase as it is for
multiple, regular 'request_update' calls, too. (although I haven't found
any explicit wording covering this?)."

In my mind I was assuming the regular request_update had this behavior,
because I remember writing that the update request queue is a "set". I
need to tweak the LRM to make this unambiguous.

Given that, we have two choices:

* Allow request_update and aync_request_update to be mixed for the same
primitive channel instance. This means that the implementation has to be
able to handle this case.

* Disallow it, which may simplify the implementation a little in the sense
that async_request_update can assume there are no regular update requests
in the queue for that primitive channel.

What does the current implementation do, David? Which way should we go?

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
David C Black <dcblack@xtreme-eda.com>, john.aynsley@doulos.com
Cc:
systemc-p1666-technical@eda.org
Date:
24/11/2010 16:09
Subject:
Re: Wording proposal for request_safe_update

John, David,

simultaneous calls to '(async_)request_thread_safe_update' and
'request_update' and are not really the key issue.

  I think, we can allow both as long as they result in a _single_ call
to 'update' in the corresponding update phase as it is for multiple,
regular 'request_update' calls, too. (although I haven't found any
explicit wording covering this?).

  The real issue is here, that the user can't arbitrarily access the
state of the current channel that actually provides this asynchronous
access (and therefore calls request_thread_safe_update internally).
Such concurrent accesses from inside the SystemC model and from other
parts of the application might need to be protected by additional,
application defined locking techniques. But this is out of the scope of
the standard. It could warrant a note, though.

Greetings from Oldenburg,
  Philipp

On 24/11/10 15:08, David C Black wrote:
>
> On Wed, Nov 24, 2010 at 4:31 AM, <john.aynsley@doulos.com> wrote:
[snip]
>> 2nd question: Are there any dependencies or interactions between
>> request_update and request_thread_safe_update? Can you have both for
the
>> same primitive channel instance? What happens?
>
> Good point, I think it should be stated that it is undefined if both are
> called. Choose one or the other.

-- 
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.