Date: Mon, 7 Apr 2003 21:10:54 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com>, "Julian Elischer" <julian@elischer.org> Cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED Message-ID: <001e01c2fd07$20b55bb0$0701a8c0@tiger> References: <Pine.GSO.4.10.10304070730480.9723-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20
From: "Daniel Eischen" <eischen@pcnet1.pcnet.com>
To: "Julian Elischer" <julian@elischer.org>
Cc: "David Xu" <davidxu@freebsd.org>; <freebsd-threads@freebsd.org>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001e01c2fd07$20b55bb0$0701a8c0>