Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Sun May 13 2001 - 00:46:05 EEST
Paul Davis wrote:
>
>
> >Perhaps you want to *read* my program,
>
> I did. first of all, you've "polluted" the cache by running both
> examples in the same process. and then ...
Would you bet some money with me that if divide the two part I get the
very same results?
From the statement above I'm tempted to suppose you have strange belief
about cache pollution.
> > I think it is an accurate enough
> >simulation of what happens with both models.
>
> Abramo! Nobody in this discussion has ever suggested a multithreaded
> solution. the two discussion points were a multiprocess solution and a
> single-threaded solution. the second part of your program models
> something that wasn't being discussed.
I repeat myself: it's a way to compute the extra cost to have multiple
process (thread implementation in linux is done with processes as you
already know) wrt to have a single process.
However if you think that the simulation is not correct and you explain
why I'm willing to do the needed changes.
I've written this small program to have some reliable numbers to use for
design decision.
> >Note that I don't suggest to implement that, but to consider it in the
> >model.
>
> no, its not part of the model. it would be an additional optimization
> of the model for certain systems. how well interthread communication
> works is an important factor in deciding how much to parallelize, but
> its not part of a single-threaded or multiprocess model.
I strongly disagree: if model and API don't take in consideration this
possibility, to add it in a second time will likely become near to
impossible.
> >multi threaded approach may be useful on some of them:
> >- component hang
> >- segmentation fault involving corruption of a limited area
> >- etc.
>
> wrong on both counts. it doesn't protect against component hang,
> because components can still hang, and there are no mechanisms offered
> by the OS to detect this before an xrun has occured; it doesn't
"Before an xrun has occured"??? Of course not... I was thinking to
something far less ambitious. A component does not answer any more? We
disable it/kill it/restart it. The one process model imply that all the
application need to be restarted.
-- 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 : Sun May 13 2001 - 01:01:04 EEST