On Wed, Sep 27, 2023 at 01:41:33PM +0200, Florian Westphal wrote: > Phil Sutter <phil@xxxxxx> wrote: > > > However, this is stalling writers and I don't think we need this > > > according to the problem description. > > > > ACK. Maybe Florian has a case in mind which requires to serialize reset > > and commit? > > No, spinlock is fine too, concurrent resets will just burn more cycles. > I did not think we'd have frequent resets which is why I suggegested > reuse of the existing lock, thats all. > > No objections to new mutex or spinlock. OK, so we may just reuse commit_mutex until we find a practical use-case for which this is a bottleneck? Or should one prefer a dedicated lock in order to reduce complexity when it comes to lock debugging? Cheers, Phil
