[concurrency-interest] how to use Thread.yield to fix ConcurrentIntArrayList

David Holmes davidcholmes at aapt.net.au
Tue Jan 9 19:08:57 EST 2018

Hi Andrew,

I have not analysed the correctness, or otherwise, of your code. I'm only pointing out that you only need to be concerned about issues around thread priority if running in a full priority-preemptive scheduling environment - in which case you have even more to worry about as OpenJDK is not designed for such an environment and may itself contain livelocks either in library code or the VM (and of course suffer from priority inversion). If you want to write your code in a way that is immune to priority issues then you can't spin indefinitely if that might prevent the thread you are waiting for from ever running - hence you need to degrade from a spin to a block.

Declaring an array reference as volatile is seldom what you need because it has no effect on accessing the array elements - a read of ar[i] will be a volatile read of ar but not of ar[i]. A write to ar[i] will be a volatile read of ar, and a plain write to ar[i].


> -----Original Message-----
> From: Andrew Nuss [mailto:andy at stagirite.com]
> Sent: Wednesday, January 10, 2018 9:53 AM
> To: dholmes at ieee.org
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] how to use Thread.yield to fix ConcurrentIntArrayList
> David,
> Are you saying that my code works on openjdk as is, or should the loops at the beginning of each of my functions, loop say 20 times,
> and then if no progress, do a Thread.sleep?  Also Brian O'Neill responded that the volatile marker to the effectively final "ar" member
> of MyArray should be final.  Does it really matter in my use case?
> Andrew
> On 01/09/2018 12:59 PM, David Holmes wrote:
> > Andrew,
> >
> > The priority-induced deadlock  you describe can only occur if you are running under a strict priority-preemptive scheduler (i.e
> SCHED_FIFO) and even then it depends on the number of processors and the number of always runnable threads and their priority.
> The OpenJDK is not designed to run in such environments - neither the algorithms in existing j.u.c classes, nor the VM itself. To solve
> your problem a thread that can't make progress must eventually block to ensure other threads can make progress.
> >
> > David
> >
> >

More information about the Concurrency-interest mailing list