Thread pools: memory barriers in task completion notifications.
The ngx_thread_pool_done object isn't volatile, and at least some compilers assume that it is permitted to reorder modifications of volatile and non-volatile objects. Added appropriate ngx_memory_barrier() calls to make sure all modifications will happen before the lock is released. Reported by Mindaugas Rasiukevicius, http://mailman.nginx.org/pipermail/nginx-devel/2016-April/008160.html.
This commit is contained in:
parent
16165af181
commit
bea9c1b085
1 changed files with 4 additions and 0 deletions
|
@ -345,6 +345,8 @@ ngx_thread_pool_cycle(void *data)
|
|||
*ngx_thread_pool_done.last = task;
|
||||
ngx_thread_pool_done.last = &task->next;
|
||||
|
||||
ngx_memory_barrier();
|
||||
|
||||
ngx_unlock(&ngx_thread_pool_done_lock);
|
||||
|
||||
(void) ngx_notify(ngx_thread_pool_handler);
|
||||
|
@ -366,6 +368,8 @@ ngx_thread_pool_handler(ngx_event_t *ev)
|
|||
ngx_thread_pool_done.first = NULL;
|
||||
ngx_thread_pool_done.last = &ngx_thread_pool_done.first;
|
||||
|
||||
ngx_memory_barrier();
|
||||
|
||||
ngx_unlock(&ngx_thread_pool_done_lock);
|
||||
|
||||
while (task) {
|
||||
|
|
Loading…
Reference in a new issue