24 Mar 2014, 22:34
David_small_pragsmall

David Whittaker (4 posts)

You asked, “won’t the lock numbers just be the index of the node in the list?” We were thinking the lock “number” would be the order the nodes are locked. But you are correct that it would still be numbered sequentially in the diagram. Perhaps it would serve to connect the rows more coherently?

You asked, “How confusing did your reading group find this [that the diagram didn’t start at the head node]?” We debated for a while whether you were trying to show that someone could have a pointer to an intermediate node.

25 Mar 2014, 11:14
Icon_pragsmall

Paul Butcher (25 posts)

Got it - thanks David!

20 Apr 2014, 04:42
David_small_pragsmall

David Whittaker (4 posts)

The topic came back up again as we were trying to figure out why if global ordering is not important for hand-over-hand locking, how can you go both ways and not dead lock? Can you point us in the direction of further reading on this?

20 Apr 2014, 18:11
Icon_pragsmall

Paul Butcher (25 posts)

Thanks (as always) David.

That the sidebar is (I now realise) rubbish. There’s nothing about the code that breaks the global ordering rule.

The global ordering rule is “Acquire multiple locks in a fixed, global order”. The important word in that sentence is “multiple”.

The size() method never holds more than one lock, so ordering is irrelevant.

I’ll update the sidebar - thanks for bringing this to my attention!

28 Apr 2014, 04:47
Generic-user-small

Vladimir Yarotsky (1 post)

Hi

While we at it, is it intentional that the isSorted() method is not acquiring any locks in the code sample (http://media.pragprog.com/titles/pb7con/code/ThreadsLocks/LinkedList/src/main/java/com/paulbutcher/ConcurrentSortedList.java)?

28 Apr 2014, 07:36
Icon_pragsmall

Paul Butcher (25 posts)

Hey Vladimir - yes it was deliberate, although I certainly wouldn’t recommend that you do this kind of thing in production code.

That method is only used in test code (see where it’s used) If ConcurrentSortedList does what it claims to do, then isSorted could be replaced by:

boolean isSorted() {
  return true;
}

:-)

In “real” code (i.e. not a cut-down example in a book) I’d structure things differently to ensure that isSorted is only ever called in non-threaded test contexts.

  You must be logged in to comment