Fix for ngx_unlock() and thus race conditions in AIO mechanism

Maxim Dounin mdounin at mdounin.ru
Tue Apr 19 16:47:08 UTC 2016


Hello!

On Tue, Apr 19, 2016 at 05:09:55PM +0100, Mindaugas Rasiukevicius wrote:

> Maxim Dounin <mdounin at mdounin.ru> wrote:
> > Patch that follows the same logic as used in ngx_update_time(), that is,
> > with an explicit ngx_memory_barrier() call before ngx_unlock(), and no
> > barrier semantics in ngx_unlock() itself:
> 
> I can just point out that pretty much all spin-lock implementations
> provide memory ordering guarantees; this is 1990s discussion which has
> been settled by now with a consensus that certain ordering guarantees
> should be provided by the synchronisation primitives.  If you will look
> into the kernels (be it Linux, BSD or Solaris -- it was Sun who de facto
> set the standard back in the day), libraries (say libpthread) or other
> projects, (e.g. PostgreSQL) -- you will find the right barrier in the
> unlock operation.
> 
> If you do not provide these guarantees, then you provide something what
> is different from a textbook implementation of a spin-lock.  It is rather
> dangerous and unlikely to prevent from bugs.

Sure, current behaviour of ngx_unlock() is different from a 
textbook one, and we may consider changing it to something more 
common, even if it means additional unneeded barriers in 
ngx_update_time().  But changing semantics and fixing bugs are 
distinct things and shouldn't be mixed whenever possible.

-- 
Maxim Dounin
http://nginx.org/



More information about the nginx-devel mailing list