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

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.

Josh


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