About Figure 6.5 Chapter 6 (v 31.01.2015)

About Figure 6.5 Chapter 6 (v 31.01.2015)

[Jose Fernando Santos de Carvalho]

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

Re: About Figure 6.5 Chapter 6 (v 31.01.2015)

[Jose Fernando Santos de Carvalho]

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



-- 
-- 
José Fernando Carvalho
DSc Candidate in Computer Science
Federal University of Pernambuco (UFPE) - Brazil

Re: About Figure 6.5 Chapter 6 (v 31.01.2015)

[Paul E. McKenney]

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

Re: About Figure 6.5 Chapter 6 (v 31.01.2015)

[Jose Fernando Santos de Carvalho]

Dear Paul,
thank you for feedback. FYI, we are using perfbook as a main reference
in our discipline.

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

Re: About Figure 6.5 Chapter 6 (v 31.01.2015)

[Paul E. McKenney]

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
>