Date: Mon, 1 Mar 1999 08:50:50 -0800 From: John Plevyak <jplevyak@inktomi.com> To: Terry Lambert <tlambert@primenet.com>, John Plevyak <jplevyak@inktomi.com> Cc: hackers@FreeBSD.ORG Subject: Re: flock and kernel threads Message-ID: <19990301085050.A21935@tsdev.inktomi.com> In-Reply-To: <199902272027.NAA13546@usr09.primenet.com>; from Terry Lambert on Sat, Feb 27, 1999 at 08:27:13PM %2B0000 References: <19990223214744.A24606@proxydev.inktomi.com> <199902272027.NAA13546@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The problem is a but in the semantics of file locking in FreeBSD because in FreeBSD kernel threads are more 'processes' than 'thread' (i.e. they have their own PID). File locking in threaded programs should work independently of which thread locked the file and which thread closes the file. It should not require registering any cleanup functions. This is how it works on Solaris, IRIX and Digital Unix, and I believe how it should work on FreeBSD. john On Sat, Feb 27, 1999 at 08:27:13PM +0000, Terry Lambert wrote: > > I believe there may be a problem with lockfiles (flock) and > > kernel threads. The problem is demonstrated by the enclosed > > program, which if run twice will fail the second time. > > > > The problem seems to be that termination via signal of > > the non-main thread (non-leader) does not (always) result > > in a call to closef and hence a call to lf_clearlock. > > > > Suggestions, comments welcome. > > This happens because fd's are scoped to the process (it's an > index intpo the per process open file table) and not to the > thread that opened them. Consider that if they were scoped > to the thread that did the open, you would not be able to do > useful things like handing incoming socket connections off to > worker threads. > > To resolve this, you either need to register a cleanup mechanism > that knows about per thread state: > > man pthread_cleanup_push > > This is less than ideal, since it means that your threading > architecture in your program is not very SMP scalable, by its > design. > > In general, thread use should be limited as much as possible > to a "work to do model", with any persistent state that will > survive across transactions scoped globally in a per "session" > state structure. > > Refeerences to the literature available on request (or you can > scan the -current and -hackers list archives). > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 110, San Mateo, CA 94403 W:(415)653-2830 F:(415)653-2801 P:(888)491-1332/5103192436.4911332@pagenet.net 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?19990301085050.A21935>