[Vm-dev] Why isn't signalSemaphoreWithIndex() thread-safe?
Igor Stasenko
siguctua at gmail.com
Mon Sep 21 02:00:28 UTC 2009
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.
More information about the Vm-dev
mailing list