Hello!

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

> Maxim Dounin <mdounin@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/

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel