#1626 Use try lock method to avoid stalling real time IO thread.

[bluelasers]

See issue for details.

[hzeller]

Do you ever experience that situation or is this the problem #1626 you think you could solve this way ?

The problem with try-lock is, that you now might never give the user a chance to update the frame as it will allow the update thread to hog the CPU solidly (as it is high-prio and if you have a single core that might starve the regular priority threads). With the actual lock you will give a chance to briefly give up that core.

[bluelasers]

This pull request is the handcuff to the issue. It is part of a process I try to follow.

I am under the impression that mutex grab is blocking. The condition wait will release the mutex from blocking. Try lock will attempt a grab is it can, but will never block. If it gets the lock it will do the condition signal, otherwise skip over it on this pass. This means the high priority thread can never block.

There is a risk of locking out the low priority thread. It is the exact same problem just in reverse. Perhaps a pipe would be better? This allows testing the ends of the pipe and making a pass if nothing is there. You need a lock on the write side of the pipe but not on the read side. I would not pass but a small struct across as you are still shared memory.

Edit:
Pipes technically have more control flow requirements.

[bluelasers]

FYI, I think we can go lockless on the high priority thread. We need a lock on the low priority side. (Issue #1678)

[hzeller]

You transfer information between threads, you can't do this without locks. You need a memory barrier.

[bluelasers]

You need to be able to control the meaning of the values and order of accesses. A lock is required serialize the memory accesses on the low side. A volatile variable can be used to control the memory accesses on the high side. A procedure will control meaning of the values. Fences/barrier and flushing may be required to make sure the values are in the correct order.

C/C++ did not provide this originally. GCC did in a semi-portable manner. Locks are the only way to really go about it in pthreads, if I understand it correctly. Pipe is expensive in some cases.

So I think I understand at least partly why it is what it is. Your saying it is still not a good idea?

[hzeller]

Closing; as discussed it is a misguided attempt to solve a problem that does not exist.