cvs commit: src/sys/kern kern_umtx.c src/sys/sys umtx.h

[Jeff Roberson]

On Mon, 31 Mar 2003, Nate Lawson wrote:

> On Mon, 31 Mar 2003, Jeff Roberson wrote:
> >   Added files:
> >     sys/kern             kern_umtx.c
> >     sys/sys              umtx.h
> >   Log:
> >    - Add an api for doing smp safe locks in userland.
> >    - umtx_lock() is defined as an inline in umtx.h.  It tries to do an
> >      uncontested acquire of a lock which falls back to the _umtx_lock()
> >      system-call if that fails.
> >    - umtx_unlock() is also an inline which falls back to _umtx_unlock() if the
> >      uncontested unlock fails.
> >    - Locks are keyed off of the thr_id_t of the currently running thread which
> >      is currently just the pointer to the 'struct thread' in kernel.
> >    - _umtx_lock() uses the proc pointer to synchronize access to blocked thread
> >      queues which are stored in the first blocked thread.
> >
> >   Revision  Changes    Path
> >   1.1       +303 -0    src/sys/kern/kern_umtx.c (new)
> >   1.1       +87 -0     src/sys/sys/umtx.h (new)
>
> It's great to be getting this.  Can you point me to a document indicating
> how this will be used by KSE?  Are we going to have "native threads"
> (thr), KSE, and pthreads?

I have not written a document for umtx.  I will probably write a man page
at some point.  I'm not sure that KSE can use umtx directly.  Their
requirements are different from thr and so this interface is slightly tied
to the thr idea of threads.

Currently you could use umtx to synchronize two processes if I wasn't
using the PROC_LOCK() in kern_umtx.c.  I could do this if there was enough
interest.  It sounds sort of neat anyway.

The only reason this is tied to threads is because the thr_id_t is the
"struct thread *".  I dont think kse currently exposes this to userland
although it could.

I'm sure I'll talk with the other kse folks at more depth about whether
nor not they can use this for the libkse locks.

Cheers,
Jeff