RE: Wording proposal for request_safe_update

Phillip,

Like I said in my first e-mail: I think we can come up with a more generic approach to the 2 sets of issues you list.
I'm not sure whether channels are the best mechanism in all cases where tools/simulators or user applications communicate with the SystemC simulation.

The problem I see is that we're inserting an API deep down in the core of the language to provide a specific solution, my fear is that there are other problems that can be solved better in a different way: are we going to add yet another interface in those cases? In the end we'll have a ton of different interfaces all for different uses at which point we didn't help the user at all and probably have overloaded the kernel with too many checks...

The goal of this group should be to make sure the core of the language remains clean, if there is a need for an ease of use layer for the end-user we can standardize that in a layer on top of the core (much like TLM, or what is being done in CCI)

Btw: aren't the 2 use cases you mention in the the domain of the CCI WG in OSCI anyway???

Bart

|-----Original Message-----
|From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
|Sent: Thursday, November 25, 2010 10:59 PM
|To: Bart Vanthournout
|Cc: john.aynsley@doulos.com; David C Black; jerome.cornet@st.com;
|systemc-p1666-technical@eda.org
|Subject: 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.