From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] cs46xx: once again SMP fixes, new aproach Date: Fri, 23 Aug 2002 10:31:07 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <3D6557B0.5070007@cucumelo.org> Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <3D6557B0.5070007@cucumelo.org> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Benny Sjostrand Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Thu, 22 Aug 2002 23:29:20 +0200, Benny Sjostrand wrote: > > > - The pcm_link/unlink only access SCB under it's related SRCTask_SCB*, > it only touches the nex_scb_ptr, parent_ptr and sub_list_ptr on > SRCTask.. so it can safely be running paralel with any other > simultaneous operation on other parts of the tree, and it can be running > paralell with others pcm_link/unlink related to other SRCTask*. > > - In create_pcm_channel the channel is initially created unlinked, which > mean pcm_link must be called before playback start, invoked by > playback_trigger. Anyway pcm_unlink was called in playback_open, which > now can be removed. In this way the pcm_reader SCB will be initially > floating, with no parent SCB and therefor we dont need any spin_lock in > create_pcm_channel. > > - But, the _same_ PCM stream, playback_trigger cant run before > playback_open has completed. Which make no sense, I supose the ALSA PCM > core prevent a process from doing this to happen. this must be ok. > - In pcm_link the PCMReaderSCB is always linked in after SRCTask* > sub_list_ptr, then therefor is no need loop searching for the last free > SCB in sublist. good, that's somewhat i thought of. > Conclusion what we got is: > - No mutexes in playback_trigger > - Independent spin_locks for each SRCTask* > - spin_lock only needed in pcm_link/unlink and in cs46xx_dsp_remove_scb. great! the patch looks more cleaner than before. > With fewer and short spin_locks, theorically we manage to have good > performance on SMP machines -:) > > That's all, ... i think ... > Question, suggestion or whatever you got in mind about this is welcome, > i'll try to be open. i'll try to run and merge to cvs later. thanks! Takashi ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390