On Fri, Jun 15, 2001 at 10:52:59PM -0400, Roland McGrath wrote: > > I have a couple of questions then. The code relies heavily on the > > use of __spin_lock operations, however they are mach specific. > > Only __spin_lock_solid is actually Mach-specific, and that only in its > implementation and not its interface. Other kernels might too have a > "yield time" system call that's appropriate. Or you could fall back to a > machine-dependent busy loop (e.g. linuxthreads/sysdeps/i386/pspinlock.c) or > a generic one. > > > Is there a standard internal iterface to locks in glibc? > > There are a few approximations, e.g. atomicity. You should steal freely from > the linuxthreads source files that say copyright Free Software Foundation (but > not the ones copyright Xavier Leroy). Much of that stuff, such as the > pspinlock.c implementations for all those machines, can just be folded in as > generic glibc implementation facilities that subsume previous > libc/linuxthreads and libc/hurd internal facilities (either renamed to be less > pthread- or linuxthreads-specific, or just used as is). > > > Otherwise most of the code already has to be moved into under sysdeps/mach. > > That doesn't make sense. Please elaborate.
All I ment was the if I can't find a generic interfaces for locking then all the code that depends on __spin_lock will have to be moved to a subdir that implies sysdeps/mach. In the extreme case what I'll do is just create stubs in sysdeps/generic, that way __spin_lock will become the standard locking interface. Thanks for all the info, I'll look into it. Igor
