Date: Tue, 2 Jan 2001 20:56:36 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Matthew Jacob <mjacob@feral.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, alpha@FreeBSD.ORG, Doug Rabson <dfr@nlsystems.com> Subject: RE: Interrupt threads Message-ID: <Pine.LNX.4.10.10101022034150.1535-100000@linux.local> In-Reply-To: <Pine.LNX.4.21.0101021218440.14503-100000@zeppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Jan 2001, Matthew Jacob wrote: > You switch to the process w/o changing IPL. It is resumed at the IPL of t= he > ithread that blocked. In the software way of looking at it, it inherits t= he > priority of the ithread until it releases the lock that caused it to be > resumed. Just a tiny question and remark: We must keep in mind (at it I have this in mind) that IPL is a thing local to a CPU but MUTEXes are global synchronisation objects. What happens if a ithread want to acquire a MUTEX owned by a thread=20 running on another CPU ? In my $0.02 humble opinion, I think that we should probably be able from an ithread to just spinlock on a MUTEX that is already owned, unless we are believing in miracles. > > > 4. What defeated me immediately upon looking at Doug's stuff is all o= f the > > > thread pri seems to be a software construct, so has no real hardware > > > linkage. Additionally, I did not take the time to try and find an eas= y way to > > > find and reschdule the proc that holds a lock if I'm trying to acquir= e it > > > from > > > an ithread and am blocking. Seems to be a bit of work there. IMO, the real issue is pointed here. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10101022034150.1535-100000>