Re: disable and the Initiialization Phase

Bishnupriya, John,

doesn't this extend to the interaction between disable() and
kill/reset()? Don't know, if this has been revised as well (otherwise
sorry for the noise), but I've seen the following:

"A suspended or disabled process can be killed or reset and an exception
can be also be thrown in it. But these shall not lift the suspension or
the disability."

I think, this is fine and very useful.

"For example, if a suspended or disabled thread is reset, it shall
restart from the beginning, and after it yields to the kernel via a
wait() statement, the thread shall go back to its suspended or disabled
state."

This is the same as in the initialisation case, isn't it?

  I think, we should keep it consistent. Either run disabled processes
until the first wait() in both init and reset, or only unwind disabled
processes in the reset case and restart them once they get enabled again.

  If I understand it correctly, the motivation is to ensure that
processes are in a well defined state, e.g. by driving stable output
signals. This could be a reasonable rationale.

Thanks,
  Philipp

On 02/09/10 16:54, john.aynsley@doulos.com wrote:
> Bishnupriya,
>
> The revised spec says:
>
> "Disabling a process before simulation has started (e.g., from one of the
> callback phases), or before the process has executed for the first time,
> shall have the following behavior:
> ? If the process was declared with dont_initialize(), then the
> disable shall take effect immediately, and the process shall not be
> eligible to run again until it is enabled
> ? If the process was not declared with dont_intialize(), then that
> implies the process has already been scheduled to run for the first time,
> and the disable shall take effect only after the first default execution
> of the process "
>
> That I don't like! LRM 4.2.1.1 says that processes are made runnable
> during the initialization phase, which occurs after elaboration. If a
> process is disabled during elaboration, I see no reason why it should
> execute during initialization. That would seem to contradict the rule that
> a process cannot get added to the set of runnable processes while it is
> disabled (Scheduling Insights para 3).

-- 
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.