[Vm-dev] linux thread priorities
eliot.miranda at gmail.com
Thu Feb 4 16:45:14 UTC 2010
Replying to mine and John's suggestion of moving the pump to the VM's check
On Wed, Feb 3, 2010 at 9:31 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
> I think one interim solution to explore is to run the sound pump from the
> VM thread in the VM's check for events code. In the Cog VMs a 1KHz
> heartbeat updates the wall clock and causes the VM to break out of native
> code and check for events (ideally the heartbeat is a separate thread). An
> mentioned, on linux the heartbeat is a software signal from an interval
> timer. The software interrupt serves also to interrupt any system calls
> (e.g. in relinquishProcessorForMilliseconds). I can extend the heartbeat to
> set a flag saying "run the sound pump" which will be checked by the VM when
> checking for events and it will invoke the sound pump code. The problem
> here is that any long-running activities that aren't interruptable by the
> software interrupt (OpenGL rendering?) will delay the sound pump. So this
> is either doomed to failure or might just work depending on those other
> activities. Comments? Try it, waste of time?
Obvious really, but this can't work. See below.
On Wed, Feb 3, 2010 at 9:44 PM, John M McIntosh <
johnmci at smalltalkconsulting.com> wrote:
> Well mmm doesn't the checkForInterrupts code get called every 1 millisecond
> (or there about?)
> Can't you add something there to ensure your sound logic doesn't starve.
> Hint if checkForInterrupts is not being called every ms or so how do you
> ensure delay accuracy is to a ms boundary?
There is no guarantee that checkForInterrupts is being called
every millisecond. There is only a guarantee that the VM will be asked
to checkForInterrupts every millisecond. It will actually check as soon as
it next checks. So if it is in a long-running primitive, or more
importantly a full garbage collection it will check when this has finished.
The GC pauses are the killer. For us every now and then there is a >100ms
pause for GC and so the sound pump will occasionally be starved.
Essentially the sound pump has to run as an interrupt or in another thread.
I am going to try one horrible hack. Right now the deadlock I'm seeing is
in the sound pump's logging code that calls ctime_r to grab an ascii string
of the local time to timestamp log entries. The VM can keep a copy of
ctime_r's result and update it synchronously every second or so, instead of
calling ctime_r on every log entry. This won't remove the possibility of
lock-up due to other library calls, but it may reduce the probability low
enough that our alpha demo will work sufficiently and give us time to work
on a proper solution (i.e. investigating Bert's direction to improved linux
schedulers) after the demo.
> next hint if checkForInterrupts is being called 10 times a millisecond then
> isn't that wasteful, should you be grinding smalltalk bytecodes or assembler
> instructions there of?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev