[lkml]   [1996]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SUMMARY: Kernel Threads Usable By Mortals (Christopher J. Shaulis)  wrote on 26.04.96 in <>:

> 2) User-mode locking
> The kernel does not provide any locking functions to help threads
> syncronise and not step all over each other. Apparently a locking
> mechanism could be hacked out of the IPC functions, but that is
> considered to be quite a dirty approach. Someone posted some code to
> the linux-smp list not long ago which implemented a spin lock in user
> mode by making use of the atomic compare and exchange instruction on
> the iX86. It is as atomic as can be, and is guaranteed
> FIFO. Unfortunately, noone ever filled in the ASM portion of the code,
> so if you come acress it in the archive, be prepaired to do a little
> ASM. I'm told that Postgres95 uses the same technique, so you might be
> able to snag the asm stuff from that.

Also, a user mode spin lock, while working even with multiple processors,
is still a busy wait. You definitely want a way for user mode threads to
block on locks.

A spin lock might be fine for deciding if you _should_ block, but not for
doing the actual blocking. In fact, even if you only use spin locks for
fast operations, you have a problem in the following scenario:

* one thread acquires the spin lock
* the threads time slice runs out
* another thread starts
* the other thread tries to acquire the spin lock

Now, the second thread will busy wait for the rest of its time slice. Even
worse, if for some reason it is scheduled again before the first thread
gets an opportunity to release the lock, it will again waste a time slice
busy waiting.

There's simply no way to get this right without some sort of help from the

MfG Kai

 \ /
  Last update: 2005-03-22 13:37    [W:0.068 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site