From owner-freebsd-current Sat Nov 30 14:49:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5312337B401 for ; Sat, 30 Nov 2002 14:49:46 -0800 (PST) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6F5843ED1 for ; Sat, 30 Nov 2002 14:49:45 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0348.cvx22-bradley.dialup.earthlink.net ([209.179.199.93] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18IGQh-0006A3-00; Sat, 30 Nov 2002 14:49:44 -0800 Message-ID: <3DE94039.5E1DEEFC@mindspring.com> Date: Sat, 30 Nov 2002 14:48:25 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Smith Cc: "current@FreeBSD.ORG" Subject: Re: Are SysV semaphores thread-safe on CURRENT? References: <20021130141711.CIZH19077.mailhost.chi1.ameritech.net@bbs.dbsoft-consulting.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Brian Smith wrote: > On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote: > >Use mmap of a backing-store file, and then use file locking to > >do record locking in the shared memory segment. > > Ok, I did this, and it actually works considerably better than > the SysV shared memory. However flock() has the same problem > as the SysV semaphores, where they block the entire process, > allowing the same deadlock situation to occur. Has this flock() > behavior changed in CURRENT? > > It seems like this behavior is much more likely to change than > the SysV code. Do you mean "flock()", or do you mean "fcntl(fs, F_SETLKW, ...)"? If you are using range locks, then you mean fcntl(). That's unfortunate: there's an easy way to convert blocking file locks into non-blocking, plus a context switch. I thought th threads library already did this for you in the fcntl() wrapper, in /usr/src/lib/libc_r/uthread/uthread_fcntl.c, but apparently it doesn't. 8-(. The easy way to do this is to convert the blocking request into a non-blocking request, with a retry; e.g., where you have a call to: err = fcntl( fd, F_SETLKW, &flock); Replace it with: while( ( err = fcntl( fs, F_SETLK, &flock)) == -1 && errno == EAGAIN) { sleep( 1); /* use nanosleep(), if 1 second is too big */ } This will cause the processor to be yielded to other threads for as long as the lock can't be acquired, an acquisititon will be retried until it succeeds (effectively, blocking only that thread in "sleep()"). The difference between F_SETLKW and F_SETLK is why I suggested the approach in the first place (FWIW). The cost of doing this is that blocking requests will not be serviced in FIFO order, as they would if F_SETLKW were being used. This may get expensive if you have a highly contended resource, because you are effectively implementing a low cost polling to obtain the lock. The answer to this is that you are not supposed to use semaphores for highly contended resources, or if you do, use a spin-lock before you use the semaphore, so you can fail early at reduced expense. Probably making the above code into an line function and/or actually modifiying the _fcntl() implementation in the threads library is the way to go. Worse comes to worse, I can give you a kernel patch so that an fcntl() to assert a blocking lock on a non-blocking fd returns the EWOULDBLOCK error, with a patch against _fcntl() similar to the code in _read(). I didn't do that this time, because I don't know how much code really depends on a lock assert on a non-blocking fd blocking anyway, and no matter how you slice it, it's still going to have the same non-FIFO ordering, unless I implemented a FIFO ordered request queue, as well (it'd have to, to be correct). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message