Thanks to everyone for help! Next time I'll look twice in mdb before starting such a question. In fact the thread I was expecting to be stuck in cv_timedwait was still waiting for another lock it could not aqcuire (within the timeout) because of heavy contention of too many threads for this lock. For some reason (I don't know yet) the superfluous call of ddi_get_lbolt made it easier for the thread to get past the initial lock and to reach the other condition check with the cv_timedwait. There was no bug, no deadlock, simply too much load. An ultimate solution to my problem would need a sequencing of locks as first come first serve which for now seems not worth the work, the additional memory and cpu usage. Nevertheless the work has not been wasted: - learned something more about cv_wait and mutexes from the discussion - have written a slim empty driver for testing such conditions - found some other things to improve in the driver
Thanks! This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
