Subject: Re: [linux-audio-dev] questions to be resolved
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon May 21 2001 - 19:47:22 EEST
>> 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?
>> 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".
--p
This archive was generated by hypermail 2b28 : Mon May 21 2001 - 20:08:04 EEST