#fork and deterministic resumption of the resulting process

Mathieu Suen mathk.sue at gmail.com
Tue Feb 5 02:07:45 UTC 2008


On Feb 5, 2008, at 2:47 AM, Joshua Gargus wrote:

> On Feb 4, 2008, at 5:19 PM, Mathieu Suen wrote:
>
>>
>> On Feb 5, 2008, at 12:51 AM, Andreas Raab wrote:
>>
>>> Terry Raymond wrote:
>>>> I think changing the semantics of fork is a way to introduce
>>>> a bug to existing code, i.e. one that is aware of the way
>>>> fork works and relies on it to work that way.
>>>
>>> I don't think you (as well as some of the other posters) really  
>>> understand what these changes do. To illustrate:
>>>
>>> p1 := p2 := p3 := nil.
>>> p1 := [p1Valid := p1 notNil] forkAt: Processor activePriority-1.
>>> p2 := [p2Valid := p2 notNil] forkAt: Processor activePriority.
>>> p3 := [p3Valid := p3 notNil] forkAt: Processor activePriority+1.
>>>
>>> Both, the first and the last case are currently deterministic and  
>>> will stay that way: p1 will be consistently non-nil when this code  
>>> is run; p3 will be consistently nil when run. This is currently  
>>> the case and remains the same after applying my changes.
>>>
>>> In the second case however, p2 may or may not be nil, depending on  
>>> whether external interrupts occur. Since that is rare, in 99.99+%  
>>> of all cases p2 will be non-nil.
>>>
>>> What I am proposing is simply to make p2 non-nil in 100% of the  
>>> cases. There is no change to those parts of the existing semantics  
>>> that are actually well-defined. The only change is that it takes a  
>>> rare non-deterministic occurrence and makes the overall behavior  
>>> consistent in this case.
>>
>> If something could happen it will happen.
>> Reading the code above now I expect it not to be determinist for  
>> p2. I admit the first time I expected p2 to get a value.
>> So now I prefer to have a critical section regarding p2.
>>
>> I would even wrote the critical section for p1 and p3 since in most  
>> of the scheduler the code is non determinist.
>> Especially for p3. The scheduler may not yield the current thread  
>> for performance reason. (But not in Squeak)
>>
>> So  I vote for the critical section.
>
> I'm not sure what you mean by critical section.  I'm assuming that  
> you mean to use explicit synchronization.  For example (using TMutex  
> from Croquet, sorry):
>
> mutex := TMutex new.
> p2 := nil.
> mutex critical: [
> 	p2 := [ mutex critical: [p2Valid := p2 notNil] ] forkAt: Processor  
> activePriority.
> ]

Yes.

>
>
> In other words, the programmer should be smart enough to do the  
> appropriate synchronization.  Is this what you mean?  That doesn't  
> seem unreasonable to me (and I say that as the guy who wrote the  
> broken code that started Andreas on this topic :-)  ).  I'm a little  
> uncomfortable with the notion of not giving processes the priority  
> explicitly requested by the programmer.

Btw priority should only give a flavor of how often a process should  
run, is not a way to make sure that one process will run before an  
other. IMHO

>
>
> Josh
>
>
>>
>>
>>
>>>
>>>
>>> Cheers,
>>> - Andreas
>>>
>>
>> 	Mth
>>
>>
>>
>>
>>
>
>

	Mth







More information about the Squeak-dev mailing list