On 07/11/2011 12:16 AM, Fons Adriaensen wrote:
On Sun, Jul 10, 2011 at 05:08:32PM +0200, rosea grammostola wrote:
After spending a week using JackSession, I don't think a
quit-without-save option should be a 'showstopper' here Fons. Especially
because JackSession makes working with JACK so
We have a variable 'int xval' that is being modified
I notice I have mixed up (switched) x and xval in my previous reply...
extern int xval;
void f(void)
{
int a, b, c, ... x, y, z;
x = xval;
// lots of code using a ... z;
}
Well, if you are content with any old possible
2011/7/11 Renato renn...@gmail.com:
On Sun, 10 Jul 2011 19:43:53 +0200 rosea grammostola wrote:
On 07/10/2011 06:33 PM, Emanuel Rumpf wrote:
http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft
Good job. I added some comments.
Thank you.
just wanted to notify that one of the
On 07/11/2011 03:45 AM, Sean Bolton wrote:
On Jul 10, 2011, at 6:34 PM, Sean Bolton wrote:
On Jul 10, 2011, at 2:41 PM, Paul Davis wrote:
do we have SMP systems these days that do not guarantee cache coherency?
Yes. PowerPC and Alpha do not. UltraSPARC v9 and ARMv6/ARM11 and later
have modes
On 11 July 2011 20:19, Olivier Guilyardi l...@samalyse.com wrote:
Good catch... Multi-core ARM devices are actually arriving massively. With
Android, there's the Motorola Atrix, the Samsung Galaxy S II, etc..
What about my toaster? :-P
I've ended up going back to Fons's pragmatism. If
On Mon, Jul 11, 2011 at 03:02:57PM +0300, Dan Muresan wrote:
Well, if you are content with any old possible value of xval (i.e. you
have no synchronization on it anywhere), you are right; but then you
might as well make xval a constant -- just use the first value it ever
had. You have no
On Monday 11 July 2011, at 22.32.08, James Morris jwm.art@gmail.com
wrote:
On 11 July 2011 20:19, Olivier Guilyardi l...@samalyse.com wrote:
Good catch... Multi-core ARM devices are actually arriving massively.
With Android, there's the Motorola Atrix, the Samsung Galaxy S II, etc..
On 11 July 2011 21:32, James Morris jwm.art@gmail.com wrote:
I've ended up going back to Fons's pragmatism. If
non-blocking/lock-free programming is so impossibly difficult,
requiring intimate hardware knowledge of numerous different
architectures then there's only one solution available
On 11 July 2011 21:50, Chris Cannam can...@all-day-breakfast.com wrote:
[...] a critical section juts across the code
just across
Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
On Mon, Jul 11, 2011 at 09:59:25PM +0300, Dan Muresan wrote:
and the NPTL code in glibc *seems* to perform a memory barrier only on
sem_post().
Wouldn't that seem quite natural ? Semas provide one-way communication.
It's the sem_post() that means there is an event to be seen by some
other
On Mon, Jul 11, 2011 at 4:50 PM, Chris Cannam
can...@all-day-breakfast.com wrote:
On 11 July 2011 21:32, James Morris jwm.art@gmail.com wrote:
I've ended up going back to Fons's pragmatism. If
non-blocking/lock-free programming is so impossibly difficult,
requiring intimate hardware
On July 11, 2011 04:50:06 pm Chris Cannam wrote:
I know taking locks in a RT process is deeply frowned upon
Likely been answered before, but good time for me to ask:
What is the reason it is not recommended?
Is it simply because of a long time involved in acquiring the lock, or is it
because
and the NPTL code in glibc *seems* to perform a memory barrier only on
sem_post().
Wouldn't that seem quite natural ? Semas provide one-way communication.
It's the sem_post() that means there is an event to be seen by some
other thread. So it has to make sure that any data related to it is
On Mon, Jul 11, 2011 at 05:15:26PM -0400, Tim E. Real wrote:
Likely been answered before, but good time for me to ask:
What is the reason it is not recommended?
Is it simply because of a long time involved in acquiring the lock, or is it
because the lock might block some other Jack thread
On Monday 11 July 2011 23:15:26 Tim E. Real wrote:
On July 11, 2011 04:50:06 pm Chris Cannam wrote:
I know taking locks in a RT process is deeply frowned upon
Likely been answered before, but good time for me to ask:
What is the reason it is not recommended?
Is it simply because of a long
The problem with e.g. a Jack callback trying to take a lock
is that the lock could be held by a non-RT thread, and you
have no idea how long it could take before that thread
releases it. Even if the Jack thread blocks waiting for
the lock, that doesn't mean the one holding the lock will
On Tue, 2011-07-12 at 00:12 +0200, Arnold Krille wrote:
Real-time means as fast as possible.
Err not really.
Real-time means Has a bounded response time, locks generally put your
completion time at the mercy of another process that is often not
designed to have a bounded response time.
[oops forgot to CC the list at first]
On 07/11/2011 11:15 PM, Tim E. Real wrote:
On July 11, 2011 04:50:06 pm Chris Cannam wrote:
I know taking locks in a RT process is deeply frowned upon
Likely been answered before, but good time for me to ask:
What is the reason it is not recommended?
On 07/12/2011 12:12 AM, Arnold Krille wrote:
On Monday 11 July 2011 23:15:26 Tim E. Real wrote:
On July 11, 2011 04:50:06 pm Chris Cannam wrote:
I know taking locks in a RT process is deeply frowned upon
Likely been answered before, but good time for me to ask:
What is the reason it is not
On 07/12/2011 12:06 AM, Fons Adriaensen wrote:
OTOH, if you have a number of threads at the same priority
as Jack's and doing audio work (e.g. to use all the CPUs of
an SMP machine) then using locks between them (but no other
threads) should be OK - depending a bit on how they are used.
So,
from my understanding, sem_post() implies a write barrier (stores have been
executed before sem_post()) and sem_wait() a read barrier (loads have to be
executed after sem_wait()).
Given that a mutex can be replaced with a semaphore initialized with 1
(then lock == sem_wait, unlock ==
For a ringbuffer you need two anyway if the buffer is longer than
one item, and you want to signal both of 'not empty' and 'not full'
in the appropriate direction.
Well, if one of the threads is periodic (like a Jack process thread)
it can use sem_getvalue() on the same semaphore to figure
22 matches
Mail list logo
