I can't find any function to give up the execution to the scheduler that the other processes can get that compute time.
I programm a realtime thread that have to be executed very smooth. So the breaks have to have the same delay. Linux scheduler isn't ready for such a task, because linux system calls and IRQ modules don't get their compute time by the scheduler. Also I have problems with the QT-Event scheduler and very short delays (usleep()) between port accesses of my thread.
I can't write a module for a HPET timer because of event interactions with my app.
Now I thought that I get less trouble if I can give up the execution directly to the scheduler and calculate the loop time of the scheduler and so the count of executions to give up for a delay.
Any hints or experiences are welcome.

The thread have to write one byte to the port 0x37A in most precise and short intervals as possible while the mouse button is pressed. If the mouse button is released the thread stops writing to the port and here it would be nice to have a system call to give up the execution, too.
With short sleeps (< 5000 usec) the QT mouse event brakes. So I think QT needs more compute time. Linux dosn't schedule at short sleep times.

I usually have no problem yielding time by using an empty select and a timeout specified. I'm not sure about sleeps for sub 5ms, and certainly RT on an intel x86 board is probably not going to be very response (see the rt wiki for reasons why).

Also, I'm not sure why people keep using usleep(). It is obsoleted and scheduled for removal from libc implementations at their own leisure. From the man page:

-Aaron

Yes, I first used nanosleep, but during all that trouble I tested all and at last usleep. It's just easier to use with one int value.
And I did now get, that it could also be a multicore bug in the scheduler with any short sleep, because on a monocore board it works fine, but very slow so not fast enough, not as fast as I need it.
Maybe I put those issues to the kernel mailing list and will have a look what they mean. It will be a very deep cut to the scheduler and modules. So that changes can be done for kernel 2.8.x or maybe kernel 3.x.x if Linus and the others think it will be a big advantage and if I want to wait so long.

Ohh, actually technically sched_yield will invoke the scheduler without blocking.

I'm still not sure this will solve your problem.

Can you also point me to the bug id / discussion where you found this information on a multicore bug? I wouldn't post that you've found a bug with linux unless you're absolutely certain (otherwise your head will be chewed off).