Subject: Re: [linux-audio-dev] mutex in process callback?
From: rm (async_AT_cc.gatech.edu)
Date: Thu Mar 27 2003 - 16:26:27 EET
On Thu, Mar 27, 2003 at 02:55:37PM +0100, Lukas Degener wrote:
> [...]
> Now my problem is: How can i make sure that swapping does not accure
> during process (playback) callback?
> [...]
> On the other hand, swapping pointers shouldn't take that long, so maybe
> this would not be a problem?
>
> Or would it make sense to try and "foresee" such a situation and avoid
> it by delaying the swapping?
>
> Any clever suggestions on this?
if i understand what you're asking correctly, you could just stash a
copy of the current pointer at the start of the process callback. then
(assuming there is only one pointer), the operation is atomic with
respect to the process callback: either it happens before you get the
copy of the pointer or not at all (since your copy of the pointer
won't be updated until the next time the callback is run). if more
than one pointer is involved stick the sets into arrays and stash the
index to the current set instead of the pointers themselves.
(you shouldn't really be running into a problem though since i assume
there is a distinct buffer which must be output 'next'. in that case
have the other processes add the buffers in order to a (lockless)
queue and have the process callback take them out when it needs them.
when it is done with them, have the process callback add them to a
second queue which acts as a pool of free buffers that are ready to be
reused. all buffers are alloc'ed in a non-rt thread and start out on
the free queue).
that said, if you're running in RT mode and no process that can swap
the pointers has a higher priority, then you shouldn't ever be
preempted in the first place (SMP issues though?).
hopefully that makes sense and is applicable.
rob
----
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: async_AT_cc.gatech.edu
This archive was generated by hypermail 2b28 : Thu Mar 27 2003 - 16:33:20 EET