Entries in concurrency (2)

Sunday
Nov012009

Squeeze more performance from Parallelism

In many posts, such as: The Future of the Parallelism and its Challenges I mentioned that synchronization the access to the shared resource is the major challenge to write parallel code.

The synchronization and coordination take long time from the overall execution time, which reduce the benefits of the parallelism; the synchronization and coordination also reduce the scalability.

There are many forms of synchronization and coordination, such as:

  • Create Task object in frameworks such as: Microsoft TPL, Intel TDD, and Parallel Runtime Library. Create and enqueue task objects require synchronization that it’s takes long time especially if we create it into recursive work such as: Quick Sort algorithm.
  • Synchronization the access to shared data.

But there are a few techniques to avoid these issues, such as: Shared-Nothing, Actor Model, and Hyper Object (A.K.A. Combinable Object). Simply if we reduce the shared data by re-architect our code this will gives us a huge benefits in performance and scalability.

Continue >   http://www.hfadeel.com/Blog/?p=160

 

Saturday
Dec062008

Paper: Real-world Concurrency

An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics:

  • Know your cold paths from your hot paths.
  • Intuition is frequently wrong—be data intensive.
  • Know when—and when not—to break up a lock.
  • Be wary of readers/writer locks.
  • Consider per-CPU locking.
  • Know when to broadcast—and when to signal.
  • Learn to debug postmortem.
  • Design your systems to be composable.
  • Don't use a semaphore where a mutex would suffice.
  • Consider memory retiring to implement per-chain hash-table locks.
  • Be aware of false sharing.
  • Consider using nonblocking synchronization routines to monitor contention.
  • When reacquiring locks, consider using generation counts to detect state change.
  • Use wait- and lock-free structures only if you absolutely must.
  • Prepare for the thrill of victory—and the agony of defeat. While I don't agree that code using locks can be made composable, this articles covers a lot of very useful nitty-gritty details that will up your expert rating a couple points.

    Click to read more ...