Re: s_lock() seems too aggressive for machines with many sockets - Mailing list pgsql-hackers

From Nils Goroll
Subject Re: s_lock() seems too aggressive for machines with many sockets
Date
Msg-id 557845B5.1010501@schokola.de
Whole thread Raw
In response to Re: s_lock() seems too aggressive for machines with many sockets  (Andres Freund <andres@anarazel.de>)
Responses Re: s_lock() seems too aggressive for machines with many sockets  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 10/06/15 16:05, Andres Freund wrote:
> it'll nearly always be beneficial to spin

Trouble is that postgres cannot know if the process holding the lock actually
does run, so if it doesn't, all we're doing is burn cycles and make the problem
worse.

Contrary to that, the kernel does know, so for a (f|m)utex which fails to
acquire immediately and thus needs to syscall, the kernel has the option to spin
only if the lock holder is running (the "adaptive" mutex).

Nils



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "could not adopt C locale" failure at startup on Windows
Next
From: Alvaro Herrera
Date:
Subject: Re: reaper should restart archiver even on standby