Re: Wording proposal for request_safe_update

Bart, John,

I still think, that the proposal covers a sufficient set of use-cases to
get included. I agree with John, that it does not hinder any future
improvements in that area.

We also have to distinguish two scenarios:

 - a SystemC implementation, providing hooks to its innards for other
   tools and simulators
 - a user application, where some components need to interact with the
   outside world in a deterministic and safe way

  For the second set of use cases, using an appropriate (primitive)
channel -- for instance a FIFO or a rendezvous in the easiest case --
can be a very helpful abstraction to encapsulate the ugly details of
manually fiddling with OS threading primitives at both ends of the
connection. Communication in SystemC is supposed to be done through
channels, right? ;-)

Greetings from Oldenburg,
  Philipp

On 25/11/10 18:50, john.aynsley@doulos.com wrote:
>
> I might agree. For what it's worth (and not wishing to open a can of
> worms) it did occur to me that the async_request_update mechanism is not
> particularly general. When I solved a similar problem years ago I did it
> with pthread mutexes and conditional variables between SystemC threads and
> non-SystemC threads rather than with primitive channels.
>
> John A
>
>
>
>
> From:
> Bart Vanthournout <Bart.Vanthournout@synopsys.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Bart Vanthournout
> <Bart.Vanthournout@synopsys.COM>
> Cc:
> David C Black <dcblack@xtreme-eda.com>, "jerome.cornet@st.com"
> <jerome.cornet@st.com>, "philipp.hartmann@offis.de"
> <philipp.hartmann@offis.de>, "systemc-p1666-technical@eda.org"
> <systemc-p1666-technical@eda.org>
> Date:
> 25/11/2010 17:26
> Subject:
> RE: Wording proposal for request_safe_update
>
>
>
>
> John,
>
> I probably don?t understand the use-case very well but wouldn?t an
> external interface be better build around an end-of-delta-cycle callback?
> That probably could serve more use cases than something uniquely build
> around channels.
>
> Bart
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Thursday, November 25, 2010 5:24 PM
> To: Bart Vanthournout
> Cc: David C Black; jerome.cornet@st.com; philipp.hartmann@offis.de;
> systemc-p1666-technical@eda.org
> Subject: RE: Wording proposal for request_safe_update
>
> Bart,
>
> I am neutral as to whether this enhancement gets included. However, I
> would say that the recent discussion on the reflector has been about minor
> technicalities, not about any fundamental disagreement over the spec.
>
> I would also say that async_request_update does not have any specific
> implications for sync. mechanisms between threads, but is a rather
> abstract API that could be implemented in various ways. I do not see it
> tying our hands in the future. But all that is just my opinion.
>
> John A
>
>
> From:
> Bart Vanthournout <Bart.Vanthournout@synopsys.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>, David C Black
> <dcblack@xtreme-eda.com>, "jerome.cornet@st.com" <jerome.cornet@st.com>,
> "philipp.hartmann@offis.de" <philipp.hartmann@offis.de>
> Cc:
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 25/11/2010 15:56
> Subject:
> RE: Wording proposal for request_safe_update
>
>
>
>
>
>
> John,
>
> As you may remember this addition got categorized as ?positive with some
> disagreement?; SNPS is in the camp of disagreement.
> The issue we see with this addition is not on the merits of this
> individual API but much more by the fact that it seems to address a very
> narrow set of use cases.
> So we would prefer that the standard defines a more generic solution that
> addresses synchronization and interfacing with other OS threads.
> Even from the discussion on this forum it is clear that there is an issue
> with this interface, so by renaming the API call we try to indicate that
> this is only intended for a small problem area? it doesn?t solve thread
> safety in SystemC, but it also isn?t a generic solution to interface from
> another application with SystemC.
>
> We would prefer that this is not standardized right now, but that a proper
> solution gets defined.
>
> Bart
>
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
> john.aynsley@doulos.com
> Sent: Thursday, November 25, 2010 10:30 AM
> To: David C Black; jerome.cornet@st.com; philipp.hartmann@offis.de
> Cc: systemc-p1666-technical@eda.org
> Subject: Re: Wording proposal for request_safe_update
>
> David, Jerome, Philipp, All,
>
> Okay, having re-read everyone's views, I propose async_request_update().
>
> Can everyone live with that?
>
> John A
>
> From:
> David C Black <dcblack@xtreme-eda.com>
> To:
> systemc-p1666-technical@eda.org
> Date:
> 24/11/2010 14:26
> Subject:
> Re: Wording proposal for request_safe_update
> Sent by:
> owner-systemc-p1666-technical@eda.org
>
>
>
>
>
>
>
>
> At some level I don't care what the name is if properly documented in the
> standard; however, we might care if it generates a lot of bad coding
> because the name is misleading. I suggest we not choose a non-misleading
> name. Unfortunately, we cannot choose a fool proof name because fools are
> always outsmarting us...
>
> On Wed, Nov 24, 2010 at 8:24 AM, David C Black <dcblack@xtreme-eda.com>
> wrote:
> Bother, I meant to reply all...
>
> ---------- Forwarded message ----------
> From: David C Black <dcblack@xtreme-eda.com>
> Date: Wed, Nov 24, 2010 at 8:17 AM
> Subject: Re: Wording proposal for request_safe_update
> To: Jerome CORNET <jerome.cornet@st.com>
>
>
> OK, I was bit too fast in replying to that (hadn't fast forwarded on other
> e-mail). I think Philipp has a point. Considering this is a rarely used
> and very specialized method, how about a really long name?
>
> simulator_async_thread_safe_request()
>
> I'm good with Jerome's async_thread_safe_request() too. I don't like
> external_thread_safe_request() as much because it could be called from an
> internal OS thread (not just a remote process).
>
> It will discourage casual use. [ NOTE: I refrained from adding the
> modifier potentially_slow_and_dangerous ;) ]
>
>
> On Wed, Nov 24, 2010 at 8:09 AM, David C Black <dcblack@xtreme-eda.com>
> wrote:
> I'm good with the name change and completely agree. Use
> request_thread_safe_update().
>
>
> On Wed, Nov 24, 2010 at 6:41 AM, Jerome CORNET <jerome.cornet@st.com>
> wrote:
> Agreed with Philipp. I am happy with request_thread_safe_update() (which
> is better
> than the original request_safe_update()), but indeed, "thread-safe" can be
> a bit
> misleading in the context of SystemC.
>
> I would also ultimately prefer something like async_request_update(),
> which additionally reflects well the use cases for this API.
>
> Jerome
>
>
> -----Original Message-----
> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
> Sent: Wednesday, November 24, 2010 12:59 PM
> To: john.aynsley@doulos.com
> Cc: bpriya@cadence.com; David C Black; Jerome CORNET;
> systemc-p1666-technical@eda.org; Jeremiassen, Tor
> Subject: Re: Wording proposal for request_safe_update
>
> John,
>
> Well, we have lots of "regular" threads in SystemC models already. Wrt.
> to these SC_THREADs, "request_update" is already perfectly safe.
>
> That's why I think a 'request_thread_safe_update' may be misleading.
> But if the wording in the LRM is clear enough, I can of course live with
> this name as well.
>
> Greetings from Oldenburg,
> Philipp
>
> On 24/11/10 12:37, john.aynsley@doulos.com wrote:
>
>> I take your point that 'request_thread_safe_update' does not express the
>> use case, but it does express exactly what the function does: it is like
>> request_update except that it is thread-safe. So I think the name
>> expresses the intent as well as anything.
>>
>> John A
>>
>>
>>
>> From:
>> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>> To:
>> john.aynsley@doulos.com
>> Cc:
>> Jerome CORNET <jerome.cornet@st.com>, "systemc-p1666-technical@eda.org"
>> <systemc-p1666-technical@eda.org>, "Jeremiassen, Tor" <tor@ti.com>,
> David
>> C Black <dcblack@xtreme-eda.com>, bpriya@cadence.com
>> Date:
>> 24/11/2010 10:46
>> Subject:
>> Re: Wording proposal for request_safe_update
>>
>>
>>
>> John, All,
>>
>> 'request_thread_safe_update' does not really express the intended
>> use-case. It shall be used, when called from 'outside the kernel' or
>> asynchronously to the kernel's scheduler.
>>
>> So, I would go for something like
>> async_request_update
>> external_request_update
>>
>> Greetings from Oldenburg,
>> Philipp
>
>
>
>
>
>

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