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

[Alexey Dokuchaev]

On Mon, Mar 31, 2003 at 05:38:13PM -0800, Julian Elischer wrote:
> 
> 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?
> 
> We will have 3 threads schemes..
> userland threads
> thr threads.. Useable by the majority of threaded apps
> KSE threads.. Useable by threaded apps that have thousands of threads
> 
> (i.e. KSE is a hybrid if userland and thr threads..)

Does this follow from your words that creating of "thousands of threads"
is better to be done in userland, versus kernel?  Because of M:N model
KSE will eventually utilize?  Pardon my unawareness; pointing me to some
document explaining all of this will also be appreciated.

./danfe