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<mailto:dcblack@xtreme-eda.com>> wrote:
Bother, I meant to reply all...

---------- Forwarded message ----------
From: David C Black <dcblack@xtreme-eda.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:philipp.hartmann@offis.de>]
Sent: Wednesday, November 24, 2010 12:59 PM
To: john.aynsley@doulos.com<mailto:john.aynsley@doulos.com>
Cc: bpriya@cadence.com<mailto:bpriya@cadence.com>; David C Black; Jerome CORNET; systemc-p1666-technical@eda.org<mailto: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<mailto: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<mailto:philipp.hartmann@offis.de>>
> To:
> john.aynsley@doulos.com<mailto:john.aynsley@doulos.com>
> Cc:
> Jerome CORNET <jerome.cornet@st.com<mailto:jerome.cornet@st.com>>, "systemc-p1666-technical@eda.org<mailto:systemc-p1666-technical@eda.org>"
> <systemc-p1666-technical@eda.org<mailto:systemc-p1666-technical@eda.org>>, "Jeremiassen, Tor" <tor@ti.com<mailto:tor@ti.com>>, David
> C Black <dcblack@xtreme-eda.com<mailto:dcblack@xtreme-eda.com>>, bpriya@cadence.com<mailto: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

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.