Lightweight locking primitive
От | Matthew Kirkwood |
---|---|
Тема | Lightweight locking primitive |
Дата | |
Msg-id | Pine.LNX.4.33.0203122052480.29753-100000@sphinx.mythic-beasts.com обсуждение исходный текст |
Список | pgsql-hackers |
Hi, It seems that the Linux kernel will very shortly acquire a lightweight userlevel locking primitive (called futexes), thanks primarily to Rusty and Hubertus. It looks to be very useful for the sort of locking that databases of various types need to do. They have a bunch of rather nice properties: a) low overhead in the no-contention case - a single locked instruction on i386 b) no kernel overhead for non-contended locks - make as many as you like, the kernel memory cost is only O(number of lockswith waiters) c) are interruptible / restartable across signals d) the name :-) They don't do: a) deadlock detection b) cleanup on process exit -- the kernel doesn't know who had the lock, so it can't help here A reader/writer version is available, though it's currently implemented with two futexes. Spin-for-a-while-before-sleeping versions are planned. The API looks like this: /* these can be stored anywhere -- mmapped file, * sysv shm, shared anonymous memory */struct futex lock; /* this does mprotect(.., ...|PROT_SEM, ...); * seemingly some architectures need to do odd * things to get atomic/coherentmemory */if(futex_region(lock, sizeof(lock))) fail("futexes not available on this kernel"); futex_init(&lock); ... /* grab the lock -- we also have a futex_trydown */if(futex_down(&lock)) fail("couldn't get lock"); /* critical section */ /* release lock */futex_up(&lock); We're looking for interesting applications to try this stuff out on. Are there: a) parts of postgresql which would like this, or b) changes to the interface (or feature set) which would make it more suited ? The LWLocks look not unlike this, but my impression is that they are low-contention, so any improvement would be small. Any pointers into appropriate bits of source would be greatly appreciated. Thanks, Matthew.
В списке pgsql-hackers по дате отправления: