Xref: utzoo comp.os.mach:881 comp.sys.next:14883 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!pacific.mps.ohio-state.edu!tut.cis.ohio-state.edu!sei.cmu.edu!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!+ From: Richard.Draves@cs.cmu.edu Newsgroups: comp.os.mach,comp.sys.next Subject: Re: problem with ports and reference counting Message-ID: Date: 29 Mar 91 04:13:47 GMT References: <1905@kgw2.Xetron.COM> Organization: Carnegie Mellon, Pittsburgh, PA Lines: 31 In-Reply-To: <1905@kgw2.Xetron.COM> > Excerpts from netnews.comp.os.mach: 26-Mar-91 problem with ports and > refe.. Dennis Glatting@kgw2.Xet (1683) > My question has to do with ports and reference counting. For > each task there is an interface library. These routines obtain > the task's port from the name server and perform a transaction. > Since we're multi-threaded, we do perform multiple transactions > with the same task from different threads within another > task. > I two threads independently look up a tasks name then (I assume) > if one thread deallocates the port then the other thread > will have problems. For example, in a msg_rpc(). The first > thread is completing a transaction (the other task sent a > reply) but hasn't run yet. The second thread then looks up the > task's port. The first thread comes back and deallocates the port. > The second thread now runs and attempts to send a message. > Therefore, we can't deallocate the port abruptly. My feeling > is that the task's will reach an equilibrium where multiple > netname_lookup()s won't consume more kernel resources. This problem can't be solved satisfactorily in user space. If one thread can do a deallocate at the same time another thread is receiving a message, the receive might happen first and then a port right in the received message can be inadvertently deallocated. Mach 2.5 programs generally don't bother to deallocate ports, or at least not send rights, so this isn't a problem. Mach 3.0's IPC interface has reference counting support to let user tasks overcome these types of races. Rich