[concurrency-interest] lockfree programming and threads ofdifferent priorities

David Holmes davidcholmes at aapt.net.au
Thu Jul 3 19:00:28 EDT 2014


As others have alluded if your "lock-free" is really a spin-lock with no
suspension, and you have a uniprocessor and are on a system where thread
priorities actually means something, then you can easily live-lock. Even on
a multi-processor you could get in the same state if multiple threads try to
acquire busy locks at the same time. Strict priority scheduling and
lock-free (busy-wait) programming do not mix very well. There is a mountain
of literature on this in the real-time world.

  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Andy Nuss
  Sent: Friday, 4 July 2014 12:04 AM
  To: concurrency-interest at cs.oswego.edu
  Subject: [concurrency-interest] lockfree programming and threads
ofdifferent priorities


  I am using a class that I wrote called SimpleLock.  It holds one
AtomicBoolean and a public lock() and unlock() method as would make sense.

  All my datastructures that have unthreadsafe members that are modified
and/or read together (often both) use the model:

  try {
      ... do some work on unthread safe private members
  } finally {


  I am seeing some deadlocks in the SimpleLock.lock() function in my various
pools of threads.  My model is to use threadpools, all threads within each
running at the same priority.  However, the various threadpools run at
different priorities.

  Currently, it is possible in a class:

  class MyDeadLockingClass {

        public add ()
          ...use SimpleLock's lock and unlock


        private remove ()
          ...use SimpleLock's lock and unlock

  For the add() and remove() functions to be called within different
threadpool threads, and thus at different thread priority.  Could this be a
big problem, or is it still safe?  My guess is that it is safe, and I have
to look for the cause of deadlocking elsewhere.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140704/8e7489f4/attachment.html>

More information about the Concurrency-interest mailing list