Fwd: Wording proposal for request_safe_update

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.