From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaroslaw Sobierski Subject: Re: Re: dmix plugin Date: Mon, 17 Feb 2003 07:32:56 -0800 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: <1045495976.3e5100a8efb9b@webmail3.namezero.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Return-path: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: abramo.bagnara@libero.it Cc: perex@suse.cz, alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org >> I see, the read/saturate/write must be atomic, too. In this case, it would >> be better to use a global (or a set of) mutex(es) to lock the hardware >> ring buffer. The futexes are nice. > >They are nice indeed, but definitely not the right solution here. > >Although I don't know if it's the absolute best solution, the 'retry' >approach I've proposed is far better and much more efficient. I have to agree with Abramo. A global mutex would cause long and unnecessary waits for the processes trying to write to the plugin. Locking access to individual parts of the buffer is messy. Notice that concurrent writes to the same sample in the buffer will occur sporadically, and the "re-read" in the loop costs almost nothing, while synchronization mechanisms could block often. -------------- Fycio (J.Sobierski) fycio@gucio.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf