Of course you can swap between THREADS very quickly. This has nothing to do with the timer interrupt : by doing a pthread_cond_wait or a pthread_cond_signal you implicitely call the sheduler ! So that the number of swaps, in your example, is only limited by your CPU.
I could have achieve the same result in the shell example I gave, if instead of simply touch/rm the file used as a lock, I had connected the two shell scripts with a lockfile.
The point was, if I understood it clearly, how longer a task can run before being interrupted by the scheduler ; so obviously the tasks must not explicitely ask the scheduler to switch task to a specified thread, which is of course done at once
The example I gave do just that : executing a 100% CPU loop and counting, by a trick, how much time these stand-alone CPU hungry processes were interrupted by force by the scheduler.
The scheduler itself is launched by timer interrupt every 1/100s, and actualy swap tasks about 1 times out of 10, so that leads us to the 0.1s of execution time by process I claimed.
Why is that the point instead of thread calling each others ? because we were talking about the vertical IRQ, adding a task for the GLX function that swaps screen, task which is not connected by any signal, as far as I understand the situation, to a given openGL application.
That’s why I doubted the nonbusy waiting functionality of GLXswappbuffer.
I may misunderstood the relations between vertical IRQ, GLX and the application, anyway. I tried to disassemble the libGLX, looking for the IRQ handler and the swappBuffer function, without results.
Someone with knoledge of the technical design of GLX could help me…
friendly waiting for your comments,