Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!apollo!hpway!mishkin From: mishkin@jrst.ch.apollo.hp.com (Nathaniel Mishkin) Newsgroups: comp.sys.apollo Subject: Re: Why do I need a "sfcb hash table mutex lock"? Message-ID: Date: 2 Jan 91 01:35:00 GMT References: <9012280914.AA03633@duc220.uni-duisburg.de> <4eed8f39.1bc5b@pisa.ifs.umich.edu> Sender: root@apollo.HP.COM Organization: r_d Lines: 17 In-reply-to: rees@pisa.ifs.umich.edu's message of 31 Dec 90 16:49 GMT In article <4eed8f39.1bc5b@pisa.ifs.umich.edu> rees@pisa.ifs.umich.edu (Jim Rees) writes: The sfcb hash table is at the heart of the IO system. It's sort of like the file table in regular Unix. It is protected by a mutex lock. The behavior you see happens when some process fails to unlock the table, usually as a result of an unexpected fault with the lock held. Correct as usual. Of course, the only code that runs with the lock held is part of the IO system itself (and a small part at that). Since this is "inner loop" code, it's written a bit more trickily than one might expect, hence the problems. However, this code has gotten (another) once over at sr10.3 and yet some more problem cases (and I think disk full is one of them) have been dealt with. -- -- Nat Mishkin Cooperative Object Computing Operation Hewlett-Packard Company mishkin@apollo.hp.com