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, and is
believed to be clean.