From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Jose Fernando Santos de Carvalho <jfsc@cin.ufpe.br>
Cc: perfbook@vger.kernel.org
Subject: Re: About Figure 6.5 Chapter 6 (v 31.01.2015)
Date: Mon, 11 May 2015 06:20:18 -0700 [thread overview]
Message-ID: <20150511132018.GG6776@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAOTdtQyGfwcSM3dL0bgeLctZ8R-Jz31Z6p00seVd_e190oe3=g@mail.gmail.com>
On Sun, May 10, 2015 at 09:42:53PM -0300, Jose Fernando Santos de Carvalho wrote:
> Dear Paul,
> thank you for feedback. FYI, we are using perfbook as a main reference
> in our discipline.
Hello, Jose,
That is very good to hear, and thank you for letting me know!
Thanx, Paul
> best regards.
>
>
> On Sun, May 10, 2015 at 5:49 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > On Sat, May 09, 2015 at 12:01:01PM -0300, Jose Fernando Santos de Carvalho wrote:
> >> Link: http://ustore1.rnp.br/ustore/faces/publicFile.xhtml?code=35e4c269403136c4a9fdb9227b704409
> >>
> >> On Tue, May 5, 2015 at 11:40 PM, Jose Fernando Santos de Carvalho
> >> <jfsc@cin.ufpe.br> wrote:
> >> > Dear all,
> >> >
> >> > while writing chapter 6 (Partitioning and Synchronisation Design), Paul has
> >> > presented five special cases about Left - and Right-Hand Locks(Figure 6.5).
> >> > However, it is not clear for me the possible problem in the fourth case
> >> > (link).
> >> >
> >> >
> >> > If possible, could anyone send some feedback about it?
> >> >
> >> > Link:
> >> > http://ustore1.rnp.br/ustore/faces/publicFile.xhtml?code=35e4c269403136c4a9fdb9227b704409--
> >> >
> >> > --
> >> > Jose Fernando
> >
> > Hello, Jose,
> >
> > You could indeed claim that the second-to-last row is safe because the two
> > ends will be operating on different pointers for element 1. Nevertheless,
> > the fact remains that both ends need to operate on element 1 simultaneously,
> > which should give us pause. Especially given that we are in a concurrent
> > environment.
> >
> > For example, suppose that thread A holds the left-hand lock and wants to
> > remove element 0. While thread A is comtemplating doing this, some other
> > thread B might hold the right-hand lock and remove element 2. We are now
> > in the state shown in the third row, and thus completely unsafe.
> >
> > Thanx, Paul
> >
>
>
>
> --
> --
> José Fernando Carvalho
> DSc Candidate in Computer Science
> Federal University of Pernambuco (UFPE) - Brazil
>
prev parent reply other threads:[~2015-05-11 13:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 2:40 About Figure 6.5 Chapter 6 (v 31.01.2015) Jose Fernando Santos de Carvalho
2015-05-09 15:01 ` Jose Fernando Santos de Carvalho
2015-05-10 20:49 ` Paul E. McKenney
2015-05-11 0:42 ` Jose Fernando Santos de Carvalho
2015-05-11 13:20 ` Paul E. McKenney [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=20150511132018.GG6776@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=jfsc@cin.ufpe.br \
--cc=perfbook@vger.kernel.org \
/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