libpthread patch
David Xu
davidxu at freebsd.org
Wed Apr 16 18:35:16 PDT 2003
----- Original Message -----
From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
To: "David Xu" <davidxu at viatech.com.cn>
Cc: <freebsd-threads at freebsd.org>
Sent: Thursday, April 17, 2003 7:46 AM
Subject: Re: libpthread patch
> On Thu, 17 Apr 2003, David Xu wrote:
>
> >
> > ----- Original Message -----
> > From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
> > To: "David Xu" <davidxu at freebsd.org>
> > Cc: <freebsd-threads at freebsd.org>
> > Sent: Thursday, April 17, 2003 5:05 AM
> > Subject: Re: libpthread patch
> >
> >
> > > There's a new patch available at:
> > >
> > > http://people.freebsd.org/~deischen/kse/libpthread.diffs
> > >
> > > This passes all the ACE tests that libc_r passes, with the
> > > exception of Cached_Conn_Test.
> > >
> > > It also seems to work with KDE, konqueror, kwrite, kmail, etc.
> > > I don't have mozilla built (and am dreading trying to), but
> > > it would be interesting to see if it works with that.
> > >
> >
> > Cool!
> >
> > > If no-one has any objections, I'd like to commit this
> > > soon. I'll let David review and comment to it first.
> > >
> > > David, I didn't add critical regions to _thr_alloc() and
> > > _thr_free(). I think that whenever they are used, we
> > > are already in a critical region or operating on an upcall.
> > >
> >
> > Hmm, I don't like to put malloc calling under critical section,
> > it is better to put it under a lock, otherwise this would cause dead
> > lock. suppose that an user thread is calling malloc(), and heap manager
> > got malloc spinlock, then it does somethings and the thread is preempted
> > by upcall from kernel, now UTS switches to another thread, that thread
> > starts to call pthread_create, so UTS kernel enters a critical region first,
> > and calls malloc, this would cause dead lock, because UTS is under critical
> > region and no context switch could happen.
>
> Hmm, I see what you mean. We could put spinlock in critical region
> and that may solve the problem, but I eventually want to see spinlocks
> go away and replace the very few that we have in libc with mutexes.
>
> > Also I don't like thr_free under critical region, I think a GC thread is still
> > needed to recycle zombie thread and free extra memory, UTS kernel
> > should't be blocked by user thread. Despite this, I think the patch should
> > be committed.
>
> I'll work on adding the GC thread back in. I really wanted to
> get rid of it so that the KSE can exit when threadcount == 0,
> but now we've got to make allowances for the extra thread
> in the main KSEG.
>
If you don't want to use GC thread, you can free extra zoombie
threads in thr_alloc(), everytime when thr_alloc is called, if it
finds there is too many zoombie threads, free them.
> Keep looking at the patch for anything else you might see.
> We still need a way to deliver signals and look for async
> cancel points in CPU-bound threads. The attempt to add a
> signal frame with signalcontext() doesn't seem to work
> which is why it is commented out.
>
I will look.
> --
> Dan Eischen
More information about the freebsd-threads
mailing list