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

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.