This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 08/01/2016 09:46 PM, Torvald Riegel wrote:
The new rwlock is built so that it supports process-shared usage, which means that we have to put everything into struct pthread_rwlock_t. This will lead to contention if you rdlock it frequently from many threads. There is potential for tuning there because we haven't looked closely at adding back-off in the CAS loop (and if you tested on an arch without direct HW support for fetch-add, the CAS loop used instead of that might also be suboptimal).
The rwlock doesn't eliminate the contention at the hardware level.If that causes a performance issue, we could reuse Ingo Molnar's brlock approach: per-thread, readers acquire their own lock, writers acquire the locks of all threads. This is fairly efficient in the read case (and I suspect you can't get much better than that in a non-managed run tine), but the write case is obviously extremely costly. This could be the right trade-off here, though.
Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |