Xref: utzoo comp.sys.mips:243 comp.arch:12058 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!mcdphx!udc!chant!aglew From: aglew@urbana.mcd.mot.com (Andy-Krazy-Glew) Newsgroups: comp.sys.mips,comp.arch Subject: Re: Mips, Mach, test-and-set Message-ID: Date: 24 Oct 89 17:19:43 GMT References: <2591@ganymede.inmos.co.uk> <6831@hubcap.clemson.edu> <326@ssp1.idca.tds.philips.nl> Sender: aglew@urbana.mcd.mot.com Organization: Work: Motorola MCD, Urbana Design Center; School: University of Illinois at Urbana-Champaign Lines: 18 In-reply-to: dolf@idca.tds.PHILIPS.nl's message of 23 Oct 89 07:36:01 GMT ..> [Deadlock avoidance by priority manipulation when synchronizing] Trouble is, changing priority usually requires kernel intervention. What we need is a fast, non-kernel, path to change priority (and also handle issues like faults in the critical section). Similarly, if the user process is trying to synchronize with an interrupt routine, then not only do you need a kernel free path for changing process scheduling priority, but also interrupt priority. Kernel-free == free of excessive kernel overhead. Fast path syscalls possible. -- Andy "Krazy" Glew, Motorola MCD, aglew@urbana.mcd.mot.com 1101 E. University, Urbana, IL 61801, USA. {uunet!,}uiucuxc!udc!aglew My opinions are my own; I indicate my company only so that the reader may account for any possible bias I may have towards our products.