[linux-dvb] About locking in the frontend thread

Sigmund Augdal sigmund at snap.tv
Mon Feb 19 12:05:30 CET 2007


I have a issue here that has made me take a closer look at the locking
done in the frontend thread, and I've found some suspicious code and an
issue needing discussion.

First the two suspicious code snippets:

1: In dvb_frontend_add_event e->status is set after the lock is
released. This I think can cause dvb_frontend_get_event to return a
incomplete/old event. The structure of the ring buffer should remain
intact so there is no potential for catastrophic failure.

2: In dvb_frontend_get_event, the code checks if the queue is empty
without taking the lock (this itself is ok), and waits if it is. However
it does not check again wether there is actually any pending events
after taking the lock. This causes a condition so that if several
threads are waiting in get_event at the same time many of them can get
spurious extra events out (seemingly an entire extra round arount the
ring buffer). Still no catastrophic failure that I can think of though.

Finally to my actual issue:
The events are added to the event queue at the very beginning of
swzigzag, and the frontend thread holds fepriv->sem. poll() will
immediatly report that new events are available, however calling
GET_EVENT on the frontend handle will block untill swzigzag has
completed and gives up the lock. Even on non-blocking filehandles. This
can for some frontends take very long time and the calling program will
just hang, even when using nonblocking io and poll() correctly. Would it
be possible to either release the lock and give the ioctl a shot at
returning or delay the actual adding of the event till the end of
swzigzag?

Regards

Sigmund Augdal

 




More information about the linux-dvb mailing list