Hello! On Tue, Apr 19, 2016 at 05:09:55PM +0100, Mindaugas Rasiukevicius wrote:
> Maxim Dounin <[email protected]> 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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
