[Vm-dev] Why isn't signalSemaphoreWithIndex() thread-safe?

[Igor Stasenko]

2009/9/21 Eliot Miranda <eliot.miranda at gmail.com>:

[snip]
>> This can be defeated by following code (wild guess)
>>
>> | proc time |
>> proc := [ [ Processor yield. ] repeat ] newProcess.
>> proc priority: Processor highestPriority.
>> proc resume.
>> time := [ 100000000 timesRepeat: [ "***" Processor yield. ] ] timeToRun.
>> proc terminate.
>> time
>
> That doesn't defeat it; it merely reduces its performance to the same
> as the original naive algorithm.

Right. This is what i wanted to illustrate. Sure thing, for typical
scenario your code is
certainly works better. :)

Btw, i am free to change my scheduler to use a linked list of
entries like:
(prioX, processesList) --> (prioY, processesList) --> ...

and simply do not waste the time & space holding the empty lists.
Or i am free to use any other scheme.. That's was the main reason for
removing the
scheduling from VM - and make it easy to improve things & correct bugs
without the need
of changing VM each time :)

>  But in a typical scenario the tide
> scheme wins big.  What is broken about the tide scheme is that
> changing a process's priority must be intercepted to correctly
> maintain the high-tide.  The code in our Qwaq images is incorrect in
> that it merely assigns the priority inst var which won't actually move
> the process onto the right run queue if it is already runnable; i.e.
> the priority: accessor can only be safely used at initialization time.
>  In VM there's a primitive that takes care of this and hence makes it
> easy to maintain the high tide correctly.
>
Right, here's the snippet from my new scheduling code :)

priority: anInteger
	"Set the receiver's priority to anInteger."
	Processor checkPriorityValue: anInteger.
	self isSuspended ifFalse: [
		"handle the potential need in rescheduling"
		Processor reschedule: self atPriority: anInteger
	] ifTrue: [ priority := anInteger ]

>
>>
>> resulting run time should be very close for both VMs, where one using
>> and another not using a new quirk.
>> I may be wrong , maybe at "****" there should be just some code , like
>> 1+1 , but not Processor yield, to make sure
>> that given loop get interrupted, but not yields execution by itself :)
>>
>> Regarding scheduling, did you taken a look of my scheduling
>> refactorings, which moving scheduling logic to image side,
>> freeing VM from any knowledge of what Semaphores is?
>> I think it could be a good move. The only thing, which is concern is
>> speed. But this could be improved by making some primitives
>> which reducing the number of sends, needed to handle the scheduling
>> (most consuming is - adding/removing to list(s)). But not rest of
>> logic, which should belong to image side.
>> And in presence of JIT, this will no longer be issue.
>>
>>>
>>> We're getting close to the end of a release cycle so I expect we'll release the Stack Cog VM soon thereafter.  Sorry for the wait so far :/
>>>>
>>>> > Cheers,
>>>> > Josh
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>



-- 
Best regards,
Igor Stasenko AKA sig.