Hi Bart- are the semantics below really safe, the don't appear to? Any caller of checker_thread_running is relaying on stale information. The c->thread_running could have changed as soon as you unlock. +static unsigned checker_thread_running(struct tur_checker_context *ct) +{ + unsigned thread_running; + + pthread_spin_lock(&ct->hldr_lock); + thread_running = ct->thread_running; + pthread_spin_unlock(&ct->hldr_lock); + + return thread_running; +} On Tue, Aug 16, 2016 at 3:11 PM, Bart Van Assche wrote: > On 08/15/2016 11:31 PM, Hannes Reinecke wrote: > >> Makes one wonder: what happens to the waitevent threads? >> We won't be waiting for them after applying this patch, right? >> So why did we ever had this busy loop here? >> Ben? >> >> (And while we're at the subject: can't we drop the waitevent threads >> altogether? We're listening to uevents nowadays, so we should be >> notified if something happened to the device-mapper tables. Which should >> make the waitevent threads unnecessary, right?) >> > > Hello Hannes, > > Maybe this is not what you had in mind, but would you agree with the > attached two patches? > > Thanks, > > Bart. > > > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel >