From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH RFC] fzsync: tst_fzsync_pair_wait exit when parent hit accidental break
Date: Mon, 07 Jan 2019 11:14:58 +0100 [thread overview]
Message-ID: <877efgn599.fsf@rpws.prws.suse.cz> (raw)
In-Reply-To: <CAEemH2eq49h48bxe17i3c_GWrbhTAHQMHr0t1_rwEdZvccJ-mg@mail.gmail.com>
Hello Li,
Li Wang <liwang@redhat.com> writes:
> Richard Palethorpe <rpalethorpe@suse.de> wrote:
>>
>> This is how it worked before, so it is fairly safe. However I don't like
>> atomically checking for the exit value on every spin of the delay
>> loop. Also because setting exit just causes it to drop through there is
>> still the (theoretical) risk of it getting stuck on another operation
>> before breaking out of thread B's main loop.
>
> Yes, and I noticed you removed the exit checking in last update, but I
> didn't realize that thread B will fall into infinite loop when parent
> is break abnormally.
Me too :-)
>
>>
>> Also removing the exit variable makes formal verification a bit easier.
>
> Good point.
>
>>
>> Another option might be to use pthread_kill with a realtime signal and
>> a signal handler which immediately exits the current thread. I am not
>> sure how much complexity that will introduce though?
>
> Well we can have a try, seems the only disadvantage of this method is
> thread_B sets signal handler at each loop start in tst_fzsync_run_b
> repeatedly.
We could wrap thread B's main function 'run_b', which is passed to
tst_fzsync_pair_reset, in another function which sets the singal handler
at the start of the thread.
>
> Not sure if I understand correctly, what drafted in my mind is:
>
> diff --git a/include/tst_fuzzy_sync.h b/include/tst_fuzzy_sync.h
> index de0402c9b..6ef6bee01 100644
> --- a/include/tst_fuzzy_sync.h
> +++ b/include/tst_fuzzy_sync.h
> @@ -63,6 +63,8 @@
> #include <time.h>
> #include <math.h>
> #include <stdlib.h>
> +#include <pthread.h>
> +#include <errno.h>
> #include "tst_atomic.h"
> #include "tst_timer.h"
> #include "tst_safe_pthread.h"
> @@ -156,8 +158,6 @@ struct tst_fzsync_pair {
> int a_cntr;
> /** Internal; Atomic counter used by fzsync_pair_wait() */
> int b_cntr;
> - /** Internal; Used by tst_fzsync_pair_exit() and fzsync_pair_wait() */
> - int exit;
I was thinking of keeping the exit variable and using the kill signal as
a backup. The reason being it should allow thread B to exit gracefully
in most scenarious. In theory this should not matter because the test
writer should not do any setup in thread B, but it might result in some
wierd error/warning messages being printed for some tests.
Unfortunately pthread_join has no timeout and pthread_timedjoin_np is
non-standard.
Another option might be to spin-wait for 'exit' to be incremented to 2
by thread B and send the signal after some arbitrarily large number of
spins. What do you think?
--
Thank you,
Richard.
next prev parent reply other threads:[~2019-01-07 10:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-04 9:52 [LTP] [PATCH RFC] fzsync: tst_fzsync_pair_wait exit when parent hit accidental break Li Wang
2019-01-04 15:02 ` Richard Palethorpe
2019-01-07 6:51 ` Li Wang
2019-01-07 10:14 ` Richard Palethorpe [this message]
2019-01-08 7:01 ` Li Wang
2019-01-08 12:48 ` Richard Palethorpe
2019-01-08 13:54 ` Cyril Hrubis
2019-01-08 14:07 ` Li Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877efgn599.fsf@rpws.prws.suse.cz \
--to=rpalethorpe@suse.de \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox