Subject: Re: [linux-audio-dev] API design again [MORE code]
From: est_AT_hyperreal.org
Date: su loka 10 1999 - 14:40:00 EDT
Paul Barton-Davis discourseth:
>
> But wait - how is the engine thread going to safely copy or otherwise
> use this data when the MIDI input thread (or any other h/w-driven
> thread) could modify the port's event list at any time ?
>
> this, it seems, is where we might be able to use a lock free queue. we
> have exactly one writer and one reader per queue, making them OK for
> the kind of logic that Eli Brandt outlined (which was thankfully not
> a Herlihy-like compare-and-swap system). as Eli pointed out, this
> does rely on pointer writes being atomic and surrounding writes not
> being reordered, which we can probably ensure.
Those lock-free-qs also look like they'd allow you to snapshot a
subsequence at a given time--e.g., record the relevant pointers for
the next set of events you want to process.
Now, have I missed something, or do those qs only work for fixed
sizes? Not that that is necessarily prohibitive.
Also, how can we know that the algorithm's requirements are met. They
probably are, but I'd like to gather sources of reassurance in this
area for future reference. For example, the glibc people say pointer
reads/writes are atomic on all systems they know of. That's one
useful datum.
> notice that the use of '<' and '>' to test for head/tail
> relations are nominal, not actual C code. if we could use fixed size
> arrays of event_t's, then we could actually use '<' and '>', but this
> seems unlikely to satisfy us.
Again, as I understood it, the algorithm uses fixed size circular
buffers.
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST