Subject: Re: [linux-audio-dev] questions to be resolved
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Mon May 21 2001 - 20:50:20 EEST
Paul Davis wrote:
>
> >> How the request is handled is an implementation detail. In my view,
> >> its an implementation detail of the engine. My own preferred way of
> >> handling this is to allow asynchronous alterations in the port
> >> connections (i.e. altering the signal graph), but to wrap it in a
> >> mutex. During the engine's cycle, it would use the semantics of
> >> pthread_mutex_trylock() to discover that it was not possible to run
> >> the graph at that time, and would fallback to whatever it would do if
> >> it had no graph at all (probably nothing at all).
> >
> >I've a better solution here in my panels (congruent read transactions).
>
> Either you're trying to implement Herlihy-style lock free
> transactions, or you haven't written enough multithreaded applications
> and run them on SMP boxes :)
>
> It seems to me self-evident that if the signal graph is in the middle
> of being modified, the engine cannot run the graph.
> It could run an old version of the graph, but that involves a deep
> copy of every data structure in the graph unless you can guarantee
> that the change in the graph does not propagate into deeper levels of
> the data structure model. In addition, such lock-free models require
> an atomic pointer swap instruction, which is not available in C or
> C++, and is not available at all on some architectures.
>
> Or perhaps you have something else in mind?
In this case we have a no-stop reader and one ore more may-stop writer.
readers and writer share the same memory that contains a copy of the
object and two integer: begin and end.
writers:
pthread_mutex_lock
begin++
wmb()
write to the area
wmb()
end++
pthread_mutex_unlock
reader:
if (cookie != end) {
cookie = end
rmb()
copy area to temp
rmb()
if (begin == end) {
copy temp to object
do what needed
}
}
Can I patent this? ;-))
> >> I don't understand the appeal (or the mechanics) or making interport
> >> connections be "internal" to a soundbox. The connections fundamentally
> >> alter the order in which a series of soundboxes must be "executed", so
> >> the engine must be able to fully determine the signal graph in order
> >> to accomplish correct execution of the graph. "correct" means "no
> >> cycle-duration delays between soundboxes unless there are feedback
> >> loops between them". So some aspect of the connections must be
> >> visible, at least to the engine.
> >
> >The engine knows everything about connections between its soundboxes,
> >but knows anything about connections internal to soundboxes.
>
> You wrote "connections are internal to a soundbox" apparently to
> indicate that you didn't follow why connections were visible at
> all. So I interpreted what you wrote to mean "connections are only
> internal to a soundbox".
Some connections are internal to soundbox (if it contains other
soundboxes), others are at application level.
-- Abramo Bagnara mailto:abramo_AT_alsa-project.orgOpera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org It sounds good!
This archive was generated by hypermail 2b28 : Mon May 21 2001 - 21:12:22 EEST