• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Reentrant lock fairness parameter in constructor

 
Ranch Hand
Posts: 226
Eclipse IDE Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.


 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Whatever. Here's a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic