From: Michael R. <mr...@us...> - 2004-01-10 14:37:47
|
Hi Miguel, Just as a minor update: I am pretty convinced now the scheme I propose works. I explained it to a friend of mine (being able to explain something is usually a good test) and I think he understood it. Whether it's a nice solution is of course another story. We have to find out. > > The video out would simply timeout the waiting in get_frame(), > > release its own port lock, sched_yield(), lock the port lock again > > and continues waiting. No returning. > > ok. > > > Post plugins should do the same (release lock, sched_yield(), grab > > lock) in some prominent places (beginning of get_frame() and open() > > like now) to allow rewiring operations to finish. > > sorry, but i don't understand how it works. the post plugin is > waiting get_frame() to return, which will never happen (paused mode), > how can it release the lock? I will try to explain it again. No, get_frame() does not return. get_frame() semantics is as it is now. The only additional constraint is that you have to grab a port lock when you want to call functions of a port or want to rewire it. This way, mutual exclusion of rewiring and port usage is assured. Now, to allow rewiring while get_frame() waits for new frames, get_frame() will timeout this waiting, and shortly releases the lock. It does not return for this and no plugin downstream needs to care. Rewiring is still safe, since ports are not used concurrently and since the thread is inside get_frame() noone else will use the port. Now we could simply wrap every port call in locking and unlocking of the port lock and things should work. But to minimize modification of the plugins, I further proposed to always call decoder plugin functions with the port lock already held, so the port lock handling is inside the decoder loops. Simple post plugins with one input and one output would not need to introduce a new port lock for their input either. They can copy the lock of their output port to their input port. This way, they know that the lock the need to call output port functions is already held, when the post plugin is called. So they don't need any modification either. Do you understand it now? Michael -- panic("Tell me what a watchpoint trap is, and I'll then deal with such a beast..."); 2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c |