NOBLE: A nonblocking interprocess communication interface

1
NOBLE A non-blocking inter-process communication
interface

• Håkan Sundell
• Philippas Tsigas
• Computing Science
• Chalmers University of Technology

2
Background

• Multithreaded programming needs communication.
• Communicating using shared data structures like
  stacks, queues, lists and so on.
• This needs synchronisation!
• Locks (Mutual exclusion) has several drawbacks,
  especially for Real-Time Systems.
• Non-blocking solutions are often complex to
  implement and having non-standard interfaces.

3
Synchronization

• Synchronization using Locks
• Uses semaphores, spinning, disabling interrupts
• Negative
• Blocking
• Priority inversion
• Risk of deadlock
• Positive
• Execution time guarantees easy to do, but
  pessimistic

Take lock ... do operation ... Release lock
4
Non-blocking Synchronization

• Lock-Free Synchronization
• Retries until not interfered by other operations
• Usually detecting interference by using some kind
  of shared variable indicating busy-state or
  similar.

Change flag to unique value, or remember current
state ... do the operation while preserving the
active structure ... Check for same value or
state and then validate changes, otherwise retry
5
Non-blocking Synchronization

• Lock-Free Synchronization
• Negative
• No execution time guarantees, can continue
  forever - thus can cause starvation
• Positive
• Avoids blocking and priority inversion
• Avoids deadlock
• Fast execution when low contention

6
Non-blocking Synchronization

• Non-blocking Synchronization
• Uses atomic synchronization primitives
• Uses shared memory
• Wait-Free Synchronization
• Always finish in a finite number of its own steps
• Negative
• Complex algorithms
• Memory consuming

TestSet Compare Swap Copying Helping Announcing
Split operation ???
7
Non-blocking Synchronization

• Wait-Free Synchronization
• Positive
• Execution time guarantees
• Fast execution
• Avoids blocking and priority inversion
• Avoids deadlock
• Avoids starvation
• Same implementation on both single- and
  multiprocessor systems

8
Schedule NOBLE

• NOBLE A non-blocking inter-process communication
  interface
• Goals
• Design
• Examples
• Experiments
• Status
• Future work

9
Goals

• Create a non-blocking inter-process communication
  interface that have these properties
• Usability
• Easy to use
• Easy to adapt existing solutions
• Efficient
• Portable
• Adaptable for different programming languages

10
Design Usability

• Data structures for multi-threaded usage
• Queues. Operations enqueue and dequeue.
• Stacks. Operations push and pop.
• Singly linked lists. Operations first, next,
  insert, delete and read.
• Snapshots. Operations update and scan.
• Data structures for multi-process usage
• Shared Register. Operations read and write.

11
Design Easy to Use

• Hide the complexity as much as possible!
• Just one include file include ltNoble.hgt
• Simple naming convention Every function is
  beginning with the NBL characters,
  likeNBLQueueEnqueue()NBLQueueDequeue() and so
  on...

12
Design Easy to adapt solutions

• Support lock as well as non-blocking solutions.
• Several different create functionsNBLQueue
  NBLQueueCreateLF() NBLQueue NBLQueueCreateLB()
  
• Unified functions for the operations, independent
  of the synchronisation methodNBLQueueFree(handle
  )NBLQueueEnqueue(handle,item)NBLQueueDequeue(h
  andle)  

13
Design Efficient

• To minimize overhead, usage of function
  pointerstypedef struct NBLQueue void
  data void (free)(void data) void
  (enqueue)(void data,void item) void
  (dequeue)(void data) NBLQueue
• Inline redirectiondefine NBLQueueFree(handle)
  (handle-gtfree(handle-gtdata))define
  NBLQueueEnqueue(handle,item) (handle-gt
  enqueue(handle-gtdata,item))define
  NBLQueueDequeue(handle) (handle-gtdequeue(handle-gtd
  ata))

14
Design Portable

• Common and identical main include file Noble.h
  for all platforms.
• Platform-independent implementation of all
  operationsinclude Platform/Primitives.h
• Platform-dependent implementations as a separate
  layer implementing CAS, TAS spin locks and
  other primitives.

15
Design Adaptable for different programming
languages

• Implemented in C, all compiled into a library
  file.
• C compatible include files and easy to make C
  wrappersclass NOBLEQueue private
  NBLQueue queuepublic NOBLEQueue(int
  type) if(typeNBL_LOCKFREE)
  queueNBLQueueCreateLF() else
  NOBLEQueue() NBLQueueFree(queue) inline
  void Enqueue(void item) NBLQueueEnqueue(queue
  ,item)...

16
Examples

• First create a global variable handling the
  shared data object, for example a stackNBLStack
  stackstackNBLCreateStackLF(10000)
• When some thread wants to do some
  operationNBLStackPush(stack, item)oritemNBLS
  tackPop(stack)

17
Examples

• When the data structure is not in use
  anymoreNBLStackFree(stack)
• To change the synchronisation mechanism, only one
  line of code has to be changed!stackNBLStackCrea
  teLB()

18
Experiment

• Set of 50000 random operations performed
  multithreaded on each data structure, with eiher
  low or high contention.
• Comparing the different synchronisation
  mechanisms and implementations available.
• Varying number of threads from 1 30.
• Performed on multiprocessors
• Sun Enterprise 10000 with 64 cpus, Solaris
• Compaq PC with 2 cpus, Win32

19
Experiments
20
Experiments
21
Status

• Multiprocessor support
• Sun Solaris (Sparc)
• Win32 (Intel x86)
• Manual in HTML.
• Webpage ready to be published.

22
Future work

• Extend to embedded systems
• Simpler uni- and multi-processor systems
• 8-bit processors with/without or different
  support for atomic synchronization primitives.
• Using timing information for lock-free
  translations to fulfill real-time systems
  properties.
• Adapt to commercial RTOS (Enea OSE).