On Mon, 18 Oct 1999 10:18:49 -0600 (MDT), Godmar Back wrote:
>Thanks for your answer, Xavier.
>
>Let me reply to some points below and ask some more questions.
>I hope this discussion remains interesting and relevant to the
>other subscribers on this list.
>
>>
>> > > I have a simple Java program where 2 threads spin in a tight loop each
>> > > grabbing the same lock and releasing it. This is on Linux x86 and has been
>> > > tested using GCJ 2.95.1, Blackdown JDK 1.1.7v3 (native threads), and
>> > > IBM JDK 1.1.8 (native threads). Note that I am on an SMP system (IBM
>> > > Netfinity Dual PIII Xeon).
>> > >
>> > > When the lock is uncontended, performance is fine: about 2,000 loop
>> > > iterations per millisecond. But with more than one thread trying to
>> > > grab the lock, performance decreases considerably: down to 25 or 30
>> > > iters/millisecond!
>>
>> I'm not surprised. Given the 1-to-1 implementation model for
>> LinuxThread, each time a thread needs to suspend (e.g. because it's
>> waiting on a locked mutex), it needs to go through the kernel and
>> trigger a context switch. Context switch in the Linux kernel is
>> pretty efficient compared with other Unix kernels, but still on the
>> order of 20 to 40 microseconds.
>
>Clearly, in the uniprocessor case, linux-threads is handicapped by
>having to ask the kernel to switch between threads, because of the
>1-to-1 implementation model. I fully agree with that.
>
>However, I think the case we're looking at here may be slightly different.
>In our case, one thread (A) is running on one CPU, and another thread (B)
>is running on another. Thread A holds a lock, thread B wants to acquire it.
>Once thread A unlocks the lock, thread B could just go ahead and run
>on the other CPU. In this case, *neither* CPU would have to context
>switch. It would simply be a system call executed on each CPU.
>
>Am I missing anything here?
What was the CPU (B) doing while waiting for the lock to be released by
CPU (A)? Normally it would not be just sitting there spinning on trying
to get the lock but rather it would be putting that thread (process) to
sleep waiting for a signal - that process is at least as much as a
context switch to get out of since that is exactly what it would do -
context switch back to the thread (process) that is asleep when the
signal comes in.
If you design a specific system that runs only two threads on two processors
then you can easily make this a special case. However, in the general
case of an OS like Linux (especially if other programs are also running
on the same system) there is a strong reason not to just loop on a lock
until you get it (unless they are micro-locks where the duration of the
lock being held is significantly less than the overhead of waking up
someone else - and even then one must look at the number of times this
happens and the number of contenders)
[...]
>> Using SysV semaphores as an alternative to mutexes is even worse:
>> you'd pay the cost of a system call on each mutex operation, not just
>> on those that contend for the mutex.
>
>Is this really true?
>Why would an implementation that uses test-and-set at user-level
>and that would fall back on the kernel lock/unlock construct not be
>applicable in this case as well as in the signal-based implementation?
Be careful here - there are other things that may be at work in a
multi-processor system and thus a system call may always need to be
involved. The overhead of such a call can be minimized in the
non-contended case but only to a certain point.
--
Michael Sinz ---- Technology and Engineering Director/Consultant
"Starting Startups" mailto:[EMAIL PROTECTED]
My place on the web ---> http://www.users.fast.net/~michael_sinz
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
