Re: disable and the Initiialization Phase

Bishnupriya,

the spec says, a disabled thread can not be added to the list of
runnable processes. So basically, the question is:

  Why does a disabled thread run until the first wait() in case
  of a reset()?

The immediate semantics imply, that unwinding and restoring of static
sensitivity should be performed ... immediately :-). But running the
reset part of a process can trigger activities in other parts of the
system. I find this really surprising for disabled processes.

My point here is: To achieve consistency, we could either run the
initialisation for disabled processes, or defer the restart of the
process' function until it is enabled/resumed again.

On the other hand, these issues are quite subtle. I think, in practice
one can work around it in case of actual problems due to this.

Thanks,
  Philipp

On 08/09/10 14:12, Bishnupriya Bhattacharya wrote:
> Philip,
>
> If I understand right, you are saying that initialisation should have same effect as reset(), and you make the particular case for disable() and initialisation. Specifically you are asking "a disabled process can be reset, why can't it be initialised"?
>
> What about suspend()? What about the other constructs? I guess you would say all process control constructs should not affect initialisation (ar at least the ones that are less powerful than reset()), and those constructs should take effect after initialisation.
>
> I don't feel convinced enough with this rationale to change the rules. Also, I think users will be more suprised with this rule than the existing ones.
>
> The way I see it, conceptually initialisation and reset are similar, but not exactly equivalent. reset() is a construct that the user explicitly issues, whereas initialisation is something that happens implicitly. reset() should be more powerful than initialisation. User-issued explicit suspend/disable can overrule initialisation, while user-issued reset() has higher priority and hence can overrule disable/suspend. That feels right to me.
>
> Thanks,
> -Bishnupriya
>
> -----Original Message-----
> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
> Sent: Friday, September 03, 2010 5:56 PM
> To: Bishnupriya Bhattacharya
> Cc: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
> Subject: Re: disable and the Initiialization Phase
>
> Bishnupriya, John,
>
> sorry for not being clear. I'll try to clarify my point.
>
> If I understand John correctly, he didn't like the fact that disabled processes may get executed during initialisation. You have proposed to change this to honour the disabled state, if it is set early enough.
>
> The re-execution of a disabled thread happens upon reset() as well.
> And since resetting a process is related to initialisation, I think the behaviour should be consistent. I really like to have few rules to remember... ;-)
>
> The steps that are performed upon reset are:
> 1. kill thread, unwind stack
> 2. reset dynamic sensitivity
> 3. start thread from beginning, run until first wait()
>
> As defined currently, disabled processes can be (asynchronously) reset and perform all three steps, even though they are disabled. This is different from the initialisation phase, if processes are skipped, even though they would have been initialised otherwise.
>
> If a disabled process is reset, it should perform steps 1+2 immediately. The question is, should it run until the first wait?
> Especially, if this is skipped for disabled processes during the initialisation?
>
> From the spec:
> "reset() shall nullify any "state" the target process may have built up during simulation, and restore it to its "state" at time 0."
>
> So what is this state at time 0?
>
> - dont_initialize is NOT set
> -> the "first wait" boundary inside the process' function
> - dont_initialize IS set
> -> outside of the process' function
>
> If we define the behaviour of disabled processes under init and reset according to this original/reset state at time 0, the behaviour could be the following for disabled processes:
>
> Initialisation:
> - d_i is set -> do not schedule/start process
> - d_i not set -> run to first wait, then stay disabled (step 3)
> (Sorry, John ;-) )
>
> Reset:
> - always unwind immediately, restore sensitivity (steps 1+2)
> - d_i is set -> do not start process function
> - d_i not set -> run to first wait, then stay disabled (step 3)
>
> This way, the interaction of init/reset and disabled processes seems to be more consistent: A reset restores the process to its state at time 0, and even disabled processes are initialised properly.
>
> What do you think?
>
> Thanks,
> Philipp
>
> On 03/09/10 12:36, Bishnupriya Bhattacharya wrote:
>> Philip,
>>
>> I'm afraid I lost you here.
>>
>> What John was pointing out was a valid discrepancy, and I've proposed a fix in the other email thread. Please review the fix and let us know if you find anything not lining up.
>>
>> Thanks,
>> -Bishnupriya
>>
>> -----Original Message-----
>> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
>> Sent: Thursday, September 02, 2010 11:23 PM
>> To: john.aynsley@doulos.com
>> Cc: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
>> Subject: 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).

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.