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
