linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Hendrik Visage" <hvjunk@gmail.com>
To: Sreevathsa <sreevathsa@gmail.com>
Cc: linux-c-programming@vger.kernel.org
Subject: Re: PThread question
Date: Mon, 19 Mar 2007 22:22:51 +0200	[thread overview]
Message-ID: <d93f04c70703191322o365d4ed3q7be76e85daf8ac29@mail.gmail.com> (raw)
In-Reply-To: <45f8f22b.0c41e030.3bf2.ffff8dda@mx.google.com>

On 3/15/07, Sreevathsa <sreevathsa@gmail.com> wrote:
> I have a question on syncing the threads. I have a scenario like this:
>
> 5 threads (T1, T2, T3, T4 & T5) are working on this piece of code:
>
> LINE1:  for(;;) {
> LINE2:          pthread_mutex_lock(&r1_mutex)

Include setting up the semaphores as discussed below ;^)

> LINE3:          .............
> LINE4:          .............
> LINE5:          pthread_mutex_unlock(&r1_mutex)
>
>
>                         /* some code that does not need protection */
> LINE6:          .............
> LINE7:          .............
>

Given the explanation below, I'd advise on another critical area here
that will block based on the FIFO. Ie. the FIFO structure will include a
pointer to two semaphores for each entry. The first one to be "READY"
and the second one to be "FINISHED".
The "FINISHED" of the Nth entry, is the "READY" for the (N+1)th entry (The
corner case of the begining/head needs to be considered too).
The initial state for these semaphores should be "down"/0 (except for the
HEAD whose READY should be "up"/1).

Thus before entry the Thread will down(FIFO[entry]->READY), and block until
the previous entry/thread upped it.
> LINE8:          pthread_mutex_lock(&r2_mutex)
> LINE9:          .............
> LINE10:                 .............
> LINE11:                 pthread_mutex_unlock(&r2_mutex)
Here you should then do up(FIFO[entry]->FINISHED)

Actually, in this way, you'll (1) serialize the processing as "Expected"
and (2) you'll do away with the pthread_mutex as you'll only be using the
semaphores in this way.
> LINE12:         }
>
>

> Now, given this scenario, here is my question:
> After T1 unlocks r2_mutex, which thread among T2, T3, T4 and T5 gets the
> r2_mutex lock? Does pthread scheduler schedule (give the lock to) thread T2
> which came to LINE8 first??

What if the threads arrived to r2_mutex in the order: T4, T2, T5, T3??

I recall some settings to the POSIX/SVR4 IPCs which will make all the processes
wake up simultaneously and all trying to regrab, and then there might be a
setting to allow them to be woken in sequence of arival, but then
still, what about
the order T4,T2,T5,T3?? I understood you'll want them processed T2,T3,T4,T5, and
that's the reason for the advice on using the semaphores.

Also check on all the other IPCs out there, as you might be able to (ab)use
the reader/writers type locks to check etc. and use yield etc. to get
the ordering right
without the corner cases and issues WRT the FIFO buffer, and it's
pointers etc. and clearing/releasing the data etc. without memory
leaks etc.

-- 
Hendrik Visage

  parent reply	other threads:[~2007-03-19 20:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-15  7:13 PThread question Sreevathsa
2007-03-15  9:14 ` krishna.vamsi
2007-03-15  9:37 ` Steve Graegert
2007-03-19 20:22 ` Hendrik Visage [this message]
2007-03-20 11:29 ` Neil Horman

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=d93f04c70703191322o365d4ed3q7be76e85daf8ac29@mail.gmail.com \
    --to=hvjunk@gmail.com \
    --cc=linux-c-programming@vger.kernel.org \
    --cc=sreevathsa@gmail.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).