From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 06:06:30 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D82937B401; Mon, 7 Apr 2003 06:06:30 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48ED743FA3; Mon, 7 Apr 2003 06:06:28 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h37D6NUp090097; Mon, 7 Apr 2003 06:06:24 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <001e01c2fd07$20b55bb0$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" , "Julian Elischer" References: Date: Mon, 7 Apr 2003 21:10:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2003 13:06:30 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "Julian Elischer" Cc: "David Xu" ; Sent: Monday, April 07, 2003 7:53 PM Subject: Re: PS_BLOCKED > On Sun, 6 Apr 2003, Julian Elischer wrote: > >=20 > > On Sun, 6 Apr 2003, Daniel Eischen wrote: > >=20 > > > On Sun, 6 Apr 2003, Julian Elischer wrote: > > > >=20 > > > > If you have this behaviour, please make it an option. Possibly > > > > One way to do this would be to call kse_create, with the > > > > 'new-ksegrp' flag set but the mailbox pointer set to NULL. > > > >=20 > > > > However why do you want to use kse_release for this. > > > > If you have only one thread in the KSEGRP then I'd call this > > > > "usleep()". > > >=20 > > > It's so that the common code (called by both scope system > > > threads and scope process threads) can be the same. I don't > > > want to have to add checks all over the place to see if the > > > KSE is bound to a thread or not. Also, nanosleep doesn't > > > work well because you can't wake it up with a KSE mailbox > > > (kse_wakeup), plus there's a race condition if you try and > > > wake it up before it actually gets to the kernel to sleep. > > > The kse_wakeup() call is latched, so if it gets to the kernel > > > first, the next kse_release() will notice it. > >=20 > > you cannot wake up a thread with no upcall mailbox using kse_wakeup > > because there is no thread mailbox address to match. >=20 > There is a kse mailbox, but no thread mailbox. I'm trying to > wakeup a KSE. What I do for multiple threaded KSEs is: >=20 > upcall_start(struct kse_mailbox *kse_mbox) > { > struct kse *curkse =3D (struct kse *)kse_mbx->km_udata; >=20 > check_completed(kse); > check_waitq(kse); > ... >=20 > while ((td_run =3D runq_first(kse->k_kseg) =3D=3D NULL) { > get_smallest_thread_wakeup_time(kse, &time_to_sleep); > kse->k_waiting =3D 1; > kse_release(&time_to_sleep) > } > /* switch to thread td_run */ > } >=20 > Although, for multiple threaded KSEs, the "while" loop > only executes once because kse_release just causes another > upcall. If another KSE makes a thread runnable in the > first KSEs KSEG's runq, then it wakes up that KSE: >=20 > _thr_setrunnable(struct kse *curkse, struct pthread *thread) > { > SCHED_LOCK(curkse); > runq_insert(thread->kseg, thread); > SCHED_UNLOCK(curkse); > if ((thread->kse->k_kseg !=3D curkse->k_kseg) && > (thread->kse->k_waiting !=3D 0)) { > thread->kse->k_waiting =3D 0; > kse_wakeup(&thread->kse->k_mbox); > } > } >=20 > or something like that. >=20 > For a single threaded KSE/KSEG, I don't want the upcall but I > still want to use kse_release(). I need to be able to wakeup > that KSE so that it may continue it's thread (it could be the > thread was in pthread_cond_wait() and it was signalled by > a thread in another KSE). And I don't want upcalls on this > KSE because there is only one thread; I don't want the overhead > of the upcall and its stack. And in order to prevent upcalls, > I have to make sure the kse mailbox has NULL in km_curthread. >=20 > That's the solution I'm looking for. I think kse_wakeup() > should be tweakable so that I don't get an upcall. >=20 Yes, I think kse_release() should be tweaked. however, because the thread is no longer an upcalling thread, so how do I deliver signal ? I still prefer to deliver signal in legacy mode, especially for = synchronized signals. > --=20 > Dan Eischen