[dm-devel] [PATCH 6/6] multipathd: Remove a busy-waiting loop

[Dragan Stancevic]

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 <bart.vanassche at sandisk.com
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20160817/491a92d9/attachment.htm>