Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Dec 2006 12:11:35 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Peter Edwards <peadar@freebsd.org>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: libpthread problem + possible solution
Message-ID:  <45830177.304@elischer.org>
In-Reply-To: <34cb7c840612151000s4a3e1f2dvd71a60d66cf7c4be@mail.gmail.com>
References:  <34cb7c840612151000s4a3e1f2dvd71a60d66cf7c4be@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Edwards wrote:
> Hi,
> 
> I've a problem when a process uses:
>        libpthread
>        detached threads
>        mixed bound/unbound threads
>        suspended threads  (a la pthread_resume_np())
> 
> whereby some newly created suspended threads don't get scheduled.
> I think I've tracked it down, so if someone could review the
> reasoning, I'd be grateful.
> 
> Newly launched threads have a "struct pthread" that may be allocated
> from a freelist of GCed threads. Apparently, when detached threads
> enter the GCed list, they can still have the "active" flag set on
> them. Later, this causes problems when this thread is recycled and
> resumed, because _thr_setrunnable_unlocked() doesn't add it to a
> run queue.
> 
> thr_cleanup can be called either from the bound-threads scheduler,
> or the unbound scheduler. One callsite clears "active", "needswitchout",
> and "lock_switch" to zero before the call. The other callsite just
> clears "check_pending". I think these flags are all either bound-thread
> or unbound-thread specific, and that there was an unintended
> assumption that the thread would remain with the same "boundedness"
> after being recycled, which isn't neccessarily the case. (Or another
> way - the idea was that there was no need to clear the "active"
> flag on a bound thread, as its only used for unbound threads, but
> a GCed bound thread might be recycled into an unbound thread)
> 
> Given that, it seems correct to clean up the thread the same way
> for both cases, and just move that code into thr_cleanup. So, does
> the attached patch make sense? I can commit it if someone gives me
> the nod. (It definitely fixes my specific problem with threads not
> getting scheduled.)


your logic sounds sound.. I'll wait for DAN to make a pronouncement however.

> 
> 
> ------------------------------------------------------------------------
> 
> Index: lib/libpthread/thread/thr_kern.c
> ===================================================================
> RCS file: /net/dyson/export/home/petere/FreeBSD-CVS/src/lib/libpthread/thread/thr_kern.c,v
> retrieving revision 1.116.2.1
> diff -u -r1.116.2.1 thr_kern.c
> --- lib/libpthread/thread/thr_kern.c	16 Mar 2006 23:29:07 -0000	1.116.2.1
> +++ lib/libpthread/thread/thr_kern.c	15 Dec 2006 17:48:20 -0000
> @@ -764,7 +764,6 @@
>  		break;
>  
>  	case PS_DEAD:
> -		curthread->check_pending = 0;
>  		/* Unlock the scheduling queue and exit the KSE and thread. */
>  		thr_cleanup(curkse, curthread);
>  		KSE_SCHED_UNLOCK(curkse, curkse->k_kseg);
> @@ -1150,6 +1149,11 @@
>  	struct kse_mailbox *kmbx = NULL;
>  	int sys_scope;
>  
> +	thread->active = 0;
> +	thread->need_switchout = 0;
> +	thread->lock_switch = 0;
> +	thread->check_pending = 0;
> +
>  	if ((joiner = thread->joiner) != NULL) {
>  		/* Joinee scheduler lock held; joiner won't leave. */
>  		if (joiner->kseg == curkse->k_kseg) {
> @@ -1717,9 +1721,6 @@
>  			 * stack.  It is safe to do garbage collecting
>  			 * here.
>  			 */
> -			thread->active = 0;
> -			thread->need_switchout = 0;
> -			thread->lock_switch = 0;
>  			thr_cleanup(kse, thread);
>  			return;
>  			break;
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> freebsd-threads@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45830177.304>