Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is the write(2) system call atomic



On Sat, 8 Apr 2006 17:20:50 -0400
"Gordon Marx" <gcmarx at gmail.com> wrote:

> Two notes: on Linux, lockf(3) is fcntl(2), and an fcntl(2) "lock" is
> advisory, so an ill-behaved program will ignore it and write with
> impunity.
This is also true. You can also include most commercial Unixes in the
above comment. 
When I had to rewrite the utmp library functions, it was important to
find out if any code we supplied wrote to utmp (and utxtmp) directly
rather than through the utmp library functions. The original problem
was that we were using a lock file, but that approach failed when there
were cases of a large number of simultaneous logins (about 1000). The
way utmp processing worked, we kept the file unlocked for the first
pass. This was acceptable because if we found the process' record, that
was unique to the process. 
Our first lock was to use lockf(3), but on a diskless system, we would
hang because lockf(3) required portmapper and the lock daemon, which
were not running when init(8) first asserted the lock. We then decided
to use flock(2) because the utmp file is always local to the processor.
Actually, we ended up writing our own system call because the semantics
changed on flock(2) because of clustering. 

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20060409/717c53f8/attachment.sig>



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org