Re: sc_prim_channel::wait (was Re: nb_peek)

All,

I have followed the discussion with attention (and I agree with the
conclusions), and I have a related question on constness, but
at a more general level. You discussed of the constness of the wait()
method, and I was wondering:
why does the norm mandate the *argument* of wait() (be it in sc_module,
sc_prim_channel or whatever) be a const reference on sc_event?

This does not seem logical, as waiting for an event can in many cases
require to modify the event. For instance, one may
want to instrument the event to record that a process has called wait()
on it.
Actually, it seems that even the base OSCI implementation actually needs
to modify the event, since it is more convenient
to keep track of the processes waiting for the event in the event class
itself. If you look at the OSCI implementation, sc_event.h,
there are several containers declared mutable to allow them to be
modified from internal functions called in the context of wait()
which rather looks as a hack to workaround the IEEE norm.

Any idea on that?

This is not essential, but another issue a constness raised by the norm
and revealed only in implementations.
I think this could be modified without any backward compatibility problem.

Jerome

On 3/30/2010 10:07 PM, Bishnupriya Bhattacharya wrote:
> John,
> I do not recollect the original discussion on this topic, but I agree
> in principle with the rationale you proivide below on why wait() is
> not declared const.
> -Bishnupriya
>
> ------------------------------------------------------------------------
> *From:* john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> *Sent:* Tuesday, March 30, 2010 9:51 PM
> *To:* Philipp A. Hartmann; Bishnupriya Bhattacharya; Stuart Swan
> *Cc:* systemc-p1666-technical@eda.org
> *Subject:* Re: sc_prim_channel::wait (was Re: nb_peek)
>
> Philipp,
>
> Aha! Now you mention it, I remember this issue of whether *wait
> *should be *const *from first time around. I think we decided that
> regardless of whether or not *wait *explicitly modifies any
> members, both logically and in terms of possible implementations
> it does alter the state of the underlying
> sc_module/sc_prim_channel object by causing a context switch, so
> it should be considered non-*const* and should not be called from
> a *const *method.
>
> Bishnupriya and Stuart - can you recall anything more?
>
> John A
>
>
> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To: john.aynsley@doulos.com
> Cc: "systemc-p1666-technical@eda.org"
> <systemc-p1666-technical@eda.org>
> Date: 30/03/2010 09:26
> Subject: sc_prim_channel::wait (was Re: nb_peek)
>
>
> ------------------------------------------------------------------------
>
>
>
> John,
>
> agreed on the nb_peek issue.
> For sc_prim_channel, see below.
>
> On 30/03/10 10:16, john.aynsley@doulos.com wrote:
> >
> > Re sc_prim_channel::wait, here's the def
> >
> > void wait( const sc_event& e )
> > { sc_core::wait( e, simcontext() ); }
>
> Note, that it should/could be (no members accessed inside):
>
> void wait( ... ) const // <- method itself should be const
>
> This way, primitive channels could call wait inside but const member
> functions. Strictly speaking, this affects sc_module::wait as well
> although processes in const functions are quite rare, I suppose.
>
> > So I guess the hack in tlm_fifo<T>::peek is out-of-date. I will
> > investigate further.
>
> Of course, inside tlm_fifo<T>::peek a direct call to
> sc_core::wait(...)
> would have been sufficient instead of the const_cast.
>
> Greetings from Oldenburg,
> Philipp
>
> --
> Philipp A. Hartmann
> Hardware/Software Design Methodology Group
>
> OFFIS
> R&D Division Transportation | FuE-Bereich Verkehr
> Escherweg 2 · 26121 Oldenburg · Germany
> Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 ·
> http://www.offis.de/
>
>
>
>
> --
> 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.