Re: pthreads imported to the Sourceforge CVS
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
Reply to: