Re: Wording proposal for request_safe_update

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.