This is a request for comments on the use of kernel synchronisation
support. As part of an attempt to implement native threads for Linux
in SRC Modula-3, I ran into a couple of problems with the user-level
support provided by things like pthreads :
(i) There seems to be no (adequate) suspend() mechanism.
(ii) They use up signals, and play around with signal masks, which
may not be what you want.
(i) was the killer, and I've implemented it in kernel-space by
tweaking the scheduler. Once I'd implemented a scheme for suspension,
it seemed fairly simple to go all the way and implement kernel-resident
locking primitives as well (the overhead is about 20 lines of kernel
code).
At the moment, the code is housed in :
(i) Some small kernel patches which provide hooks into the kernel.
(ii) A loadable module which actually implements the locking
system (thus, semantics and interface are mutable according
to taste, and the maintenance burden shouldn't be too high).
The purpose of this post is to try and decide whether to continue
work on this with a view to putting it in the kernel release, or
whether I should release the kernel patches as patches - obviously,
I'd prefer to put it in the kernel (the actual patches are quite
small), but on the other hand it is bloat. I have some
pre-pre-pre-alpha code that people can look at which is available
at http://www.cl.cam.ac.uk/users/rrw1000/ksynch.html - there
is a patch, a module, and some example programs in the 'user'
subdirectory.
Note that this module doesn't work on SMP systems yet - suspend()
needs to force a reschedule, and not having an SMP system to play
with, I'm not quite sure how to do this (or if it would work if
I did), and it hasn't been tested extensively yet.
The kernel patch is against 2.1.15, but should be fairly portable.
Richard.