Joachim Worringen wrote: > Garrett D'Amore wrote: >> I don't think the semaphore buys you anything. Additionally, it suffers >> from being subject to priority inversions, so I generally try to steer >> clear of semaphores unless I really do have a situation where the >> problem is expressed as a resource counting problem. (And even then, >> direct access to the resources with a lock and cv seems to work better >> for me at least.) > > Maybe I phrased it wrong: I was afraid I *had* to use a semaphore (as I > have to do for Linux), although I'd prefer a mutex. Everything is fine now. > >> You can certainly sleep while holding an ordinary priority mutex. It >> just might do bad things for performance, and you have to worry about >> possible recursive scenarios. > > Which performance impacts do you think of now - the lack of concurrency > while paging in, or something else?
A full pagefault excursion, which could include something like going to disk for the page, is a long time to hold a mutex - even if you're certain that nothing in the pagefault codepath could also want that mutex (I suspect Garrett is correct - that advice applies to IO and related drivers that could be involved in the full pagefault path). Your driver is re-entrant (all drivers are) so any of the driver entry points can be active at the time you're holding this mutex (usually one of the reasons you need a mutex in the first place) and may need to acquire the mutex you hold - they'd be waiting a needlessly long time. Of course that is a general guideline; you may analyze your driver and determine there are no such penalties or that they are harmless. You need to analyzse your driver with a very substantial understanding of the framework context that it will be running in. Cheers Gavin _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
