Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Reentrant lock fairness parameter in constructor

 
Nick Widelec
Ranch Hand
Posts: 226
Eclipse IDE Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Having this description from this http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantLock.html javadoc. I am little puzzled by the following bit:


The constructor for this class accepts an optional fairness parameter. When set true, under contention, locks favor granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order. Programs using fair locks accessed by many threads may display lower overall throughput (i.e., are slower; often much slower) than those using the default setting, but have smaller variances in times to obtain locks and guarantee lack of starvation. Note however, that fairness of locks does not guarantee fairness of thread scheduling. Thus, one of many threads using a fair lock may obtain it multiple times in succession while other active threads are not progressing and not currently holding the lock.


What's the relation between fairness of locks and fairness of threads?
When set true, under contention, locks favor granting access to the longest-waiting thread.
.
It means that it just suggests a kind of scheduling, however at the end of it it's the system who decides right?

Thanks in advance.


 
Henry Wong
author
Marshal
Pie
Posts: 21127
78
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nick Widelec wrote:
What's the relation between fairness of locks and fairness of threads?
When set true, under contention, locks favor granting access to the longest-waiting thread.
.
It means that it just suggests a kind of scheduling, however at the end of it it's the system who decides right?



Scheduling applies to runnable threads. The scheduler chooses the next runnable thread to execute -- based on priority, time since last run, etc. And yes, all current JVM implementations do use the native scheduler to schedule the thread, and hence, it is the system that does the "fairness of threads".

Lock fairness applies to blocked threads -- specifically, the threads that are blocked on the lock. It is the lock that decides which thread to moved into the runnable state, and hence, can be scheduled. The other threads are still blocked, and hence, can't be scheduled.

Henry
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic