Synchronising threads 1

1
Synchronising threads 1

• As weve seen, threads use shared data, and weve
  looked at how locks are used to protect the data
  while a thread is changing it.
• Quite often more is involved the way the
  threads use the data requires synchronisation
  e.g. one thread must wait to use data until
  another thread has set it up
• Typical tools for synchronisation include
  mailboxes, queues, and message passing. These are
  provided by the operating system. While their
  implementation in the operating system involves
  careful use of appropriate locks, the user does
  not need to get involved with such tricky
  details.
• A thread that tries to empty a mailbox is
  suspended if it is empty, and waits until some
  other thread puts something in the mailpox. It
  then empties the mailbox and continues.
• With queues, various threads may post data, i.e.
  put it on the queue, while others pend on the
  queue, i.e. try to get something off the queue,
  waiting for it to be there if the queue is empty.
• Queues are very useful. An example is a print
  queue the print thread takes the next file to
  be printed from the queue and prints it if
  there is nothing to be printed the thread is
  suspended. Any thread that needs to get a file
  printed puts it on the queue if the queue was
  empty that wakes up the print thread.

2
Synchronising threads 2

• Message passing - threads can achieve mutual
  exclusion and/or synchronise using messages which
  they send(destination,message) and
  receive(source,message)
• Both sending and receiving can be blocking or
  non-blocking
• Blocking send, Blocking receive both sender and
  receiver threads are suspended until the message
  is received sometimes called a rendezvous
• Non-blocking send, blocking receive the sender
  keeps going without waiting to ensure the message
  has arrived. Behaves like a queue. Probably most
  useful version.
• Non-blocking send, non-blocking receive both
  sender and receiver keep going.
• Blocking send, non-blocking receive not much
  used
• Various addressing schemes are used for
  identifying the source and the destination.
• Various approaches to message priority, and to
  lost messages.
• Concept can be scaled up to synchronising
  threads/processes on different machines in a
  distributed environment.

3
Deadlock 1

• Get the mutual exclusion or synchronisation
  wrong, result can be deadlock
• Two (or more) threads are suspended, each waiting
  on a resource held by the other as neither can
  proceed they never get to hand back the resources
  they hold, so remain suspended forever- deadlock
• e.g.
• Thread 1 Thread 2
• get resource A get resource B
• get resource B get resource A
• return resource B return resource A
• return resource A return resource B
• Most of the time, the above threads will run
  fine.
• But when (it will happen) Thread 2 breaks in
  after Thread 1 has got A and before it gets B,
  Thread 2 will get B but be suspended when it
  tries to get A. Thread 1 can now resume, but will
  be suspended when it tries to get B. Both are now
  suspended, each waiting on the other to do
  something deadlock

4
Deadlock 2

• Deadlock can involve many more than two threads,
  and the chain of requirements can be quite long,
  making deadlock harder to detect. See the Dining
  Philosophers problem for a standard example.
• All thats needed for deadlock is
• Resources cannot be shared, i.e. be in use by
  two threads at one time
• Threads keep resources until finished with them
  they cannot be forced to give them back earlier
  no pre-emption
• Threads acquire resources piecemeal as they need
  them, holding those theyve got while waiting to
  get others
• With these conditions satisfied, we can now have
• A circular pattern of threads suspended waiting
  for resources held by other suspended threads -
  deadlock

5
Deadlock 3

• Can prevent by removing one of the necessary
  conditions
• Allow pre-emption let a thread grab a resource
  that another thread is using. May then need to
  restart grabbed-from thread all over again -
  wasteful, and may get trapped in a cycle of
  restarting.
• Best bet is to deny the piecemeal grab, hold and
  wait. e.g. Force thread to grab all
  resources it will need when it starts
  wasteful, as most of the time resources are not
  being used
• or Insist all threads get resources in a certain
  order, e.g. always resource A before resource B
  still somewhat wasteful, but not too bad. (
  Prove that this works )
• Can avoid
• Check when each resource is requested that
  deadlock cant result, refuse allocation if it
  can. Bankers algorithm but takes processing
  time.
• Can detect
• If deadlock only happens very rarely, may be
  feasible to simply let it happen, detect it, and
  restart the system. But if its not rare
• All of the above approaches have problems.
• Dealing with Deadlock is a serious problem for
  operating systems, which must manage perhaps
  hundreds of threads sharing many resources.

6
Deadlock in Java (1)

• / In the code on the next few slides, two
  objects of class Resource are created, and two
  threads set up which access them both. Each
  object has a lock which is used correctly (using
  Javas synchronized()) to protect it while it is
  being used by a thread. Despite this things go
  wrong. Why? Whats the cure ?
• /
• class Resource
• String name
• public Resource(String name)
• this.name name

7
Deadlock in Java (2)

• class Mythread extends Thread
• Resource first,second
• public Mythread(Resource usefirst, Resource
  usesecond)
• first usefirst
• second usesecond
• public void run()
• while (true)
• System.out.println(Thread.currentThread().ge
  tName())
• synchronized(first)
• System.out.println(first.name)
• synchronized(second)
• System.out.println(second.name)

8
Deadlock in Java (3)

• / This creates two Resource objects and two
  threads. Both threads use the two objects, and
  behave the same way except that one thread tries
  to use the chalk first, then the duster, whereas
  the other thread tries to do it the other way
  round.
• /
• class Mydeadlock
• public static void main(String args)
• Resource chalk new Resource(Chalk")
• Resource duster new Resource(Duster")
• Mythread t1 new Mythread(chalk,duster)
• Mythread t2 new Mythread(duster,chalk)
• t1.start()
• t2.start()

9
More on Deadlock

• You need to have a good understanding of
  deadlock.
• See the handouts given in class, in particular
  the A unified Treatment of Deadlock paper by
  Shub, and the treatment of the Bankers algorithm
  in the OGorman textbook.
• You will be expected to understand and be able to
  give a good account of deadlock, including the
  material in the Shub paper.
• You will be expected to be familiar with the
  Bankers Algorithm and to able to apply it.
• Process-resource dependencies are often modelled
  using Resource Allocation Graphs or similar
  constructs, so that deadlock issues become
  essentially questions in graph theory. We look at
  this in class, but only at a superficial level.
  You are not expected to know the details of the
  related graph algorithms.