Re: Wording proposal for request_safe_update

John, David,

I agree, that in most use-cases I can think of, you won't want to call
both versions. So I'm fine with making the effects undefined (and not
require an implementation to detect this).

Thanks,
  Philipp

On 25/11/10 14:42, David C Black wrote:
> I personally don't think the idea of a channel calling both request
> mechanisms in the same cycle is a good idea. The idea is to create special
> channels for the *async_request_update*. The async version will always have
> a performance penalty to ensure safety.
>
> When I looked at the code and considered the issue, I realized it would be
> bad if that happened with the implementation I had; however, it was easy to
> make it resilient. I added a separate pointer for the safe vs normal
> sc_prim_channel mechanisms. This adds a small space overhead with no
> performance penalty (unless you count construction time during elaboration).
> So you can call both mechanisms with the net result that update will be
> called twice. Since I think this should be discouraged, I don't think it is
> a bad thing. At least the code is now "safe" from that scenario.
>
> Of course an sc_prim_channel derived class could have an internal flag that
> it uses to determine which of the two it will use (for its duration).
>
> *BOTTOM LINE*: I suggest adding text to the effect:
>
> An * sc_prim_channel* object shall not call both *request_update* and
> *async_request_update
> *. The results of violating this are undefined.
>
> On Thu, Nov 25, 2010 at 4:06 AM, <john.aynsley@doulos.com> wrote:
>
>> 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://www.offis.de/
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.