4

I'm reading a POSIX threading book for some practice, and I was trying to work out where I'd need mutex guards in a simple singly-linked list as a little practice problem. For example, if I had a list of node structures:

template <typename T>
struct Node
{
    Node<T>* next;
    T data;
};

Node<T>* head = NULL;

//Populate list starting at head...


[HEAD] --> [NEXT] --> [NEXT] --> [NEXT] --> [...] --> [NULL]

and I had two or more threads. Any thread can insert, delete, or read at any point in the list.

It seems if you just try and guard individual list elements (and not the whole list), you can never guarantee another thread isn't modifying the one the next* pointer points to, so you can't guarantee safety and maintenance of invariants.

Is there any more efficient way to guard this list than making all operations on it use the same mutex? I would have thought there was but I really can't think of it.

Also, if it were a doubly linked list does the situation change?

Tudor
  • 61,523
  • 12
  • 102
  • 142
John Humphreys
  • 37,047
  • 37
  • 155
  • 255
  • Is this a purely theoretical exercise or are you implementing a more concrete data structure like queue, stack, hash table, etc. Particularly efficient locking strategies can be devised for each of these cases. – Tudor Jan 31 '12 at 15:44
  • This was theoretical - I'll probably focus on the other ones later for more practice :) – John Humphreys Jan 31 '12 at 16:19

2 Answers2

3

If you want to-do a fine-grained locking approach with a singly linked list (i.e., one lock per node), then you will need to-do the following:

  1. Add two sentinel nodes to the list for the head and tail. Both these nodes have locks associated with them, and every new node will be added between the two of them.
  2. For ever function that traverses the list, you need to obtain a lock on the next node before you assign it to a current pointer. You also cannot release the lock on the current node until you've obtained the lock on the next node. If you are also using a prev pointer for traversal, you will keep the lock on that "previous" node until you re-assign the prev pointer to the current pointer.
  3. For adding a node, you will need to lock the two nodes that are going to be on either side of the node you're adding. So for instance, you would have a prev node pointer, and a current node pointer. You would first lock the mutex on the prev node, and then lock the mutex on the current node, and add the new node in-between the prev and current node.
  4. If you are removing a node, you would again lock the mutex in the prev and current node (in that order) and then you can remove the current node.

Keep in mind that steps #3 and #4 work because of step #2 where traversing the list requires obtaining locks on the nodes. If you skip that step, you will end up creating dangling pointers and other problems related to mis-assigned pointers as another thread changes the topology of the list underneath the current thread.

Jason
  • 31,834
  • 7
  • 59
  • 78
  • Ok, this seems to be a working strategy, but how feasible is it to implement in practice? It seems to create more problems with manipulating locks than it solves... – Tudor Jan 31 '12 at 15:22
  • If the problem is "avoid locking the whole list", then its about the best you can do. Wherever did you get the idea that fine-level concurrency was easy? :) – Scott Hunter Jan 31 '12 at 15:25
  • Typically you would use a spin-lock rather than a syscall with a `pthread_mutex_t` ... thus it actually works pretty good as long as you don't perform an operation that causes a thread to block while it's traversing the list. If your linked-list has a high-level of contention, then this method is much faster than a global mutex on the list. It benchmarks I've done that had a random mix of `add` and `remove` calls with threads in a tight loop, it can be at least 2-3x faster that having each thread wait on the global mutex. – Jason Jan 31 '12 at 15:28
2

Since locking a single node is not thread-safe (one thread might try to insert after it, while another is busy deleting the next node), neither is locking a subset of the nodes. Your best bet is to use a global mutex for the entire list, unless you're willing to put some effort into developing a read-write lock, which would at least allow several threads to read the list at the same time.

Since a doubly-linked list is an even more complicated structure, I would maintain the same advice.

Tudor
  • 61,523
  • 12
  • 102
  • 142
  • You can do fine-grained locking with a linked list. See chapter 9 of ["The Art of Multiprocessor Programming"](http://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0123705916) by Herlihy and Shavit. – Jason Jan 31 '12 at 15:14