[vdr] Re: vdr-1.3.17: thread issues with vdr-xine andvdr-osdteletext

[pasi.juppo@iki.fi]

On 21 Dec, Rainer Zocholl wrote:
> pasi.juppo@iki.fi 20.12.04 18:56
> 
>>Not sure about x86 environment but denying interrupts for a while
>>would allow atomic operation but I believe this is high prohibited
>>method when writing code for consumer OSes such as Linux. 
>>In embedded SW this is sometimes allowed - but should be avoided there also.
> 
> Yes, but instead blocking the system for some ns
> you will at least block it for several ms.
> Disable / enable interrupts are "priviledges" commands and can't
> be used in user mode.

True. That's why I noted that this kind of approach should be avoided.


> Too you can't inhibit DMA transfers or switching to another CPU
> in a multiprocessor system.
> The "lock"-prefix does ensure "exclusiveness"  and the "test and set" 
> or the "exchange (+ test)" commands guaranties atomic operation.

Ah, of course multi-processor envinronment cannot be protected just by
denying interrupts. Why I didn't remember those..


>>Using tools such as Doxygen can provide class diagrams (useful for
>>plain C code as well) that can help to make necessary modifications to
>>the code to get it thread safe.
> 
> Several booby traps are not obvious.

No but diagrams help a lot to detect them. Booby traps require often
thorough code walkthrough and even then they are not always obvious.

This is not by any means the final solution for documentation and
problem solving but it is a tool that can be used for development
without too much additional work.


>>I suggested to use Doxygen here. 
>>It generates automatically quite nice
>>looking documentation. 
> 
> Doxygen is nice, to display WHAT is done.
> But Doxygen can't NEVER know WHY it is done.
> and what the code is expected to do.

No. If that level of documentation is ever needed for VDR then Klaus can
forget coding for a while and do nothing but documenting for several
coming months (I believe he is doing VDR anyway as a hobby project thus
only few hours per week is spent on this project).

For the "what code is expected to do" question Doxygen do provide some
sort of solution. File header, function/method and inline comments with
doxygen tags (comments are already there - they just need prefix) can be
used to describe what the code is supposed to do. When code is written
nicely, comments need to explain what it is expected to do and not the
code itself (example of stupid commenting: i=0;  // Set counter to
zero), which can be easily read from the code itself.


>>This would be very helpful for
>>other developers - plugin and patch makers.
> 
> VDR has a "make doxygen".

Didn't know that. Have to take a closer look at it :)


> But there is not (overview) doc which mutex, semaphores, fifos, 
> threads etc. are used when/why and for what purpose.

Those are difficult (or impossible) to explain purely in source file
comments so doxygen is out in this case. Preferably some sort of
specification (functional and/or technical - depending on the case) to
clear them up. Who's willing to do that? Or better yet, who knows VDR's
cuts (in addition to Klaus) so well that is able to write such a
document?

-- 
t. Pasi