Re: VSTa, tsync, user level semaphores

Andrew Valencia <vandys@cisco.com> San writes:

>> >His first mail to me asked why I was using an infinite-loop
>> >spinlock to protect the user-level semaphore structures:
>>
>> Because, statistically, it won't be held (since it protects only a few
>> instructions) and it is much, much cheaper than dropping into the kernel.
>> Having yield() available might be a plus.

What I was wondering is that if some thread scheduling policies
make it impossible to do spin-waiting. If a higher priority thread
preempts a lower priority thread which is manipulating a semphore
state, the higher priority thread must somehow give up the CPU.
It is a statistically very rare case, yet once that happens, the
thread or the scheduler must do something to prevent locking up
the whole process.

I don't think this won't happen in the current VSTa's scheduler,
as the higher priority thread which is spinning eventually
will get a lower priority than the thread holding the semaphore's
lock and get preempted. Is this right?

Since I'm quite unhappy about the performance of unix IPC semaphores
(it even checks permissions every time because IPC semaphores
are independent of shared memory), the user level semaphores
will be a very attractive feature (among others).

>> Yes, we already bounced this around. I guess it isn't as important until I
>> get my dual-Pentium motherboard. Please, no floating point jokes. I am
>> seriously out wangling for a dual processor system, at which point I can
>> start playing with SMP again.

I'm glad to hear that. A free SMP-capable true mirokernel!

Thanks for your comments.

---
Masato Kataoka
kataoka@dbg.bs1.fc.nec.co.jp