Re: Help using DMX_SET_BUFFER_SIZE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



linux-dvb-request@xxxxxxxxxxx wrote:
> 
> 
> Possible solutions:
> 
> 2) enable the resize of a live ring buffer.
> Currently:
> 
> dvb_dvr_write DOES     lock the mutex (dmxdev->mutex)
> dvb_dvr_read  DOES NOT lock the mutex (the code to lock the mutex is there, but commented out, why?)
> 
> Is it enough to lock the mutex in dvb_dvr_read?

No, it isn't!

dvb_dmxdev_ts_callback is the function writing in the dvr_buffer, not dvb_dvr_write (which must be a 
system call I think).

Things get more complicated... I've understood that a callback function cannot sleep, so a mutex 
must not be used.
And a relocation of the buffer counts as reading and writing.

> Then the new function to change the buffer size could just lock the mutex, change the size and unlock.

How many readers of the dvr can there be? It looks like only 1 (otherwise the mutex would not be 
commented out).
Is it legal to write an application that reads dvr from one thread/process, and calls other ioctl 
from an other? I guess not, for the same reason why it cannot read from 2 threads.

So, if the above is true, I only need to synchronize with dvb_dmxdev_ts_callback, i.e. acquire the 
same spin_lock.

Does it make sense?

PS: It seems that I am replying my own emails... and I do that while I discover and understand more 
about the architecture of the dvr/demux.
What is a good starting point to get an idea about all those synchronization issues?
My next reading is the "Unreliable Guide To Locking".

More to follow...


_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux