Why does a thread, on ubuntu 2.6.38-generic or 3.0.0-lowlatency kernel, block another thread from taking mmap_sem?

If I write a thread and run it on the Round Robyn Real-Time scheduler, in Ubuntu 11.04 using either the shipped 2.6.38 generic kernel or the available 3.0.0-9-lowlatency kernel from开发者_开发知识库 this ppa: https://launchpad.net/~abogani/+archive/ppa, it seems to lock out the command: apt-key get

It appears to lock that command out when gpg, under the hood, tries to use mlock(), which as I understand it requires the mmap_sem. However, my test thread is literally "doing nothing", in that it is just an empty for loop. I am not also proactively using the mmap_sem, for example.

On a SMP machine (4 cores, 8 logical cores), a single thread on the RR scheduler at a priority of 50 or more seems to always lock out apt-key. A lower priority returns roughly 50% or less of the time, sometimes taking minutes to return.

What is the connection between my empty-for-loop thread at this real-time priority and the mmap_sem?

From this site: http://www.icir.org/gregor/tools/pthread-scheduling.html

The thread will contend with all the other threads and processes for the CPU. So if your thread is higher priority and is in real time scheduling, it will take the CPU and never give it back.

One way to test if this is the problem is to block on any system call, so your thread will sleep and let the other process run. Using a select with a timeout should be a good test.