> 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