Date: Sat, 27 Feb 1999 20:43:33 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jplevyak@inktomi.com (John Plevyak) Cc: hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads Message-ID: <199902272043.NAA14007@usr09.primenet.com> In-Reply-To: <19990224165840.A19033@proxydev.inktomi.com> from "John Plevyak" at Feb 24, 99 04:58:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, I found the problem with using kernel threads and fcntl( .. F_SETLK ..). > The issue is two fold. > > 1. the locks are keyed off pid, and if the first thread to exit and close > them is not the one that took out the lock the close will occur without > the lock being removed. Probably the correct way to deal with this is to put the locks into seperate collision domains for the keying. A very simple way to do this would be to take the NFS server locking kernel patches from www.freebsd.org/~terry/, and then make rpid the same as pid for unthreaded process, the same as the thread ID for threaded processes, and then make the rpid value significant for both hash bucket selection and locally asserted locks. This would result in the locks locking against each other. > 2. the P_ADVLOCK flag is set in p_flags on a per processes basis, so > we don't even check to see if locks need to be removed if the > closing (struct proc*) is not the locking (struct proc*). POSIX is very explicit, that the first close on a file within a single process results in the locks being deasserted. I think that your patches fail to address this issue, since in reality, I believe that you want to treat each thread as if it were a seperate process for the purpose of specifying POSIX close semantics. The patches also have the coeslescence problem that made me seperate the VOP_ADVLOCK code into an assert-veto/affirm-coelesce, instead of what they do now. Basically, the problem is that when you assert a byte range lock on a file (e.g., a read lock), and an overlapping lock is granted to another thread in your process (e.g. a read lock with some overlap), and one or the other of the locks (but not both) are deasserted, then the overlapping region is no longer read locked for the thread that did not release it's lock. In effect, the locks cast "shadows" onto a linear contention space for each file, and shadows with the same indices are coelesced. The purpose in dealing with this for NFS server locking is that a single process in user space proxies the locks for a large number of clients, and locks from one client machine that overlap another lock from the same client machine results in a condition similar to multiple threads within the same process asserting locks, and expecting them to be enforced as if they weren't in the same contention domain (it happens to clean up VFS advisory locking on union FS stacking at the same time, but that's just a nice side effect). As a general comment on your original problem, the correct way to handle signals (according to the pthreads model) is to disable disnals in all threads but one, which is designated as the signal handling thread. One problem here is that FreeBSD kernel threads using rfork get different PID's, so the signal handling will never work correctly anyway. For user space threads and the Linux crap, the signal handling should be possible, if you follow the disallow-all-but-one-thread rule. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902272043.NAA14007>