[EMAIL PROTECTED] (Nathan Myers) writes: > I wonder about the advisability of using spinlocks in user-level code > which might be swapped out any time. The reason we use spinlocks is that we expect the lock to succeed (not block) the majority of the time, and we want the code to fall through as quickly as possible in that case. In particular we do *not* want to expend a kernel call when we are able to acquire the lock immediately. It's not a true "spin" lock because we don't sit in a tight loop when we do have to wait for the lock --- we use select() to delay for a small interval before trying again. See src/backend/storage/buffer/s_lock.c. The design is reasonable, even if a little bit offbeat. regards, tom lane
- [HACKERS] Assuming that TAS() will succeed the first tim... Tom Lane
- Re: [HACKERS] Assuming that TAS() will succeed the ... Nathan Myers
- Re: [HACKERS] Assuming that TAS() will succeed ... Tom Lane
- Re: [HACKERS] Assuming that TAS() will succ... Nathan Myers
- Re: [HACKERS] Assuming that TAS() will ... Dominic J. Eidson
- Re: [HACKERS] Assuming that TAS() ... Nathan Myers
- Re: [HACKERS] Assuming that TAS() will ... Tom Lane
- Re: [HACKERS] Assuming that TAS() will succ... Alfred Perlstein
- Re: [HACKERS] Assuming that TAS() will ... Tom Lane
- Re: [HACKERS] Assuming that TAS() ... Bruce Momjian
- Re: [HACKERS] Assuming that TA... Alfred Perlstein
- RE: [HACKERS] Assuming that TAS() will succeed the ... Mikheev, Vadim
- Re: [HACKERS] Assuming that TAS() will succeed ... Nathan Myers