On Wed, Jun 18, 2014 at 3:56 PM, Andres Freund <[email protected]> wrote: >> > I'm looking at the way you did this in the context of the atomics >> > patch. Won't: >> > s_init_lock_sema(volatile slock_t *lock) >> > { >> > static int counter = 0; >> > >> > *lock = (++counter) % NUM_SPINLOCK_SEMAPHORES; >> > } >> > >> > lead to bad results if spinlocks are intialized after startup? >> >> Why? > > Because every further process will start with a copy of the postmaster's > counter or with 0 (EXEC_BACKEND)?
Oh, true. Maybe we should randomize that. >> > Essentially mapping new spinlocks to the same semaphore? >> >> Yeah, but so what? If we're mapping a bajillion spinlocks to the same >> semaphore already, what's a few more? > > Well, imagine something like parallel query creating new segments, > including a spinlock (possibly via a lwlock) at runtime. If there were > several backends processing such queries this they'd all map to the same > semaphore. Yeah. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
