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

[Dragan Stancevic <dragan.stancevic@canonical.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1294 bytes --]

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@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@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2373 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]