[EMAIL PROTECTED] 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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
