[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#503162: libc6: Doubt with nptl




Freeing a variable...

>       if (err = pthread_rwlock_unlock(q->data->rwlock)) {

...and using it later is never a good idea. This is a problem in your
program, closing the bug.

? Can you please explain where am I freeing a variable? AFAIK
"pthread_rwlock_unlock" function releases the lock but not delete it.
May be you thought about the "pthread_rwlock_destroy"?
http://opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_unlock.html
http://opengroup.org/onlinepubs/007908799/xsh/pthread_rwlockattr_destroy.html

The initial problem which caused this report is solved now, thats right. I just
misunderstood the manual: "The calling thread acquires the read lock if a
writer does not hold the lock and there are no writers blocked on the lock." -
- "If" here really means "if" but not "if and only if".
But I still don't understand why the SCHED_FIFO mechanism didn't work
the expected way.
Petr Salinger's note was right: "May be scheduling of whole process have
to be set, may be it have to have enough priviledge to set SCHED_FIFO.
Or the manual does not reflect glibc reality."
1) I thought about the privileges to and tried to run the process with the
root privileges - it didn't help.
2) There is nothing in manuals about the whole process sheduling:
"If the Thread Execution Scheduling option is supported, and the
 (!) threads involved (!) in the lock are executing with the scheduling
policies SCHED_FIFO or SCHED_RR, the calling thread shall not
acquire the lock ... "
3) If manual does not reflect the glibc reality then it should be fixed
as I understand.
Of course it's not a big deal but I just want to look into that.

Alexey Salmin

Reply to: