linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Kacur <jkacur@redhat.com>
To: Clark Williams <williams@redhat.com>
Cc: John Kacur <jkacur@redhat.com>,
	rt-users <linux-rt-users@vger.kernel.org>
Subject: [PATCH 3/3] rt-tests: pi_stress: Remove racy state variables that cause watchdog to trigger
Date: Thu, 19 Nov 2009 17:35:15 +0100	[thread overview]
Message-ID: <1258648515-7566-4-git-send-email-jkacur@redhat.com> (raw)
In-Reply-To: <1258648515-7566-3-git-send-email-jkacur@redhat.com>

When using pthread_barrier_wait, it is important that barriers are called
the correct number of times. That is - the same number given as the count
when initializing the barrier.

There was a do-while loop around elevate_barrier in the med priority thread.
On most machines, it actually never looped.

On threads with enough processors (nehalem for example), there was a racy
situation in which the high priority thread could come out of the finish
barrier, and before it could set high_has_run = 0, the medium priority
thread would test the value and call the elevate barrier an extra time.

This patch removes the bogus loop and related state variables and fixes
the hang.

Signed-off-by: John Kacur <jkacur@redhat.com>
---
 src/pi_tests/pi_stress.c |   22 +++++++---------------
 1 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/src/pi_tests/pi_stress.c b/src/pi_tests/pi_stress.c
index f4b43ed..6f1a309 100644
--- a/src/pi_tests/pi_stress.c
+++ b/src/pi_tests/pi_stress.c
@@ -201,8 +201,6 @@ struct group_parameters {
 	int loop;	/* boolean, loop or not, connected to shutdown */
 
 	/* state variables */
-	volatile int high_has_run;
-	volatile int low_unlocked;
 	volatile int watchdog;
 
 	/* total number of inversions performed */
@@ -703,7 +701,6 @@ void *low_priority(void *arg)
 		}
 		/* wait for priority boost */
 		debug("low_priority[%d]: entering elevated wait\n", p->id);
-		p->low_unlocked = 0;	/* prevent race with med_priority */
 		status = pthread_barrier_wait(&p->elevate_barrier);
 		if (status && status != PTHREAD_BARRIER_SERIAL_THREAD) {
 			error
@@ -711,7 +708,6 @@ void *low_priority(void *arg)
 			     p->id, status);
 			return NULL;
 		}
-		p->low_unlocked = 1;
 
 		/* release the mutex */
 		debug("low_priority[%d]: unlocking mutex\n", p->id);
@@ -812,15 +808,12 @@ void *med_priority(void *arg)
 			return NULL;
 		}
 		debug("med_priority[%d]: entering elevate state\n", p->id);
-		do {
-			status = pthread_barrier_wait(&p->elevate_barrier);
-			if (status && status != PTHREAD_BARRIER_SERIAL_THREAD) {
-				error
-				    ("med_priority[%d]: pthread_barrier_wait(elevate): %x",
-				     p->id, status);
-				return NULL;
-			}
-		} while (!p->high_has_run && !p->low_unlocked);
+		status = pthread_barrier_wait(&p->elevate_barrier);
+		if (status && status != PTHREAD_BARRIER_SERIAL_THREAD) {
+			error ("med_priority[%d]: pthread_barrier_wait(elevate): %x", p->id, status);
+			return NULL;
+		}
+
 		debug("med_priority[%d]: entering finish state\n", p->id);
 		status = pthread_barrier_wait(&p->finish_barrier);
 		if (status && status != PTHREAD_BARRIER_SERIAL_THREAD) {
@@ -906,7 +899,6 @@ void *high_priority(void *arg)
 			}
 			pthread_mutex_unlock(&shutdown_mtx);
 		}
-		p->high_has_run = 0;
 		debug("high_priority[%d]: entering start state (%d)\n", p->id,
 		      count++);
 		status = pthread_barrier_wait(&p->start_barrier);
@@ -928,7 +920,7 @@ void *high_priority(void *arg)
 		debug("high_priority[%d]: locking mutex\n", p->id);
 		pthread_mutex_lock(&p->mutex);
 		debug("high_priority[%d]: got mutex\n", p->id);
-		p->high_has_run = 1;
+
 		debug("high_priority[%d]: unlocking mutex\n", p->id);
 		pthread_mutex_unlock(&p->mutex);
 		debug("high_priority[%d]: entering finish state\n", p->id);
-- 
1.6.2.5


      reply	other threads:[~2009-11-19 16:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-19 16:35 [PATCH 0/3] rt-tests: pi_stress fixes John Kacur
2009-11-19 16:35 ` [PATCH 1/3] rt-tests: pi_stress: Use a pthread_mutex_t for the global variable shutdown John Kacur
2009-11-19 16:35   ` [PATCH 2/3] rt-tests: pi_stress: Check whether quiet is set, before taking shutdown_mtx John Kacur
2009-11-19 16:35     ` John Kacur [this message]

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=1258648515-7566-4-git-send-email-jkacur@redhat.com \
    --to=jkacur@redhat.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=williams@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).