2011/8/20 Emanuel Rumpf :
> Technologies as Mono and LLVM appear to make that (using different progr.
> languages) possible.
>
... and Java.
"Microsoft submitted a portion of its .Net framework to a standards
body, but Heffner estimates it amounts to only 10%, ..."
( source: http://www.computer
On 08/20/2011 01:24 PM, Emanuel Rumpf wrote:
2011/7/20 Kai Vehmanen:
PS My plan B is to wait and see for another 10 years (and many more
long threads about this topic on this list), and then
I can at least just start using C++0x already... ;)
It's called C++11 now and accepted by ISO al
2011/7/20 Kai Vehmanen :
>
> PS My plan B is to wait and see for another 10 years (and many more
> long threads about this topic on this list), and then
> I can at least just start using C++0x already... ;)
It's called C++11 now and accepted by ISO already ;)
2011 April 11 --- C++11, passed
Hi,
thanks folks for the annual ringbuffer thread, it's always a pleasure to
read (and you learn something new at every iteration). ;)
On Tue, 12 Jul 2011, Dan Muresan wrote:
I wonder if
{
pthread_mutex_t dummy = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&dummy);
pthread_mutex_unlock(&d
On Wed, Jul 13, 2011 at 10:28 AM, Gabriel Beddingfield
wrote:
>> i don't see why this is needed. its trivial to demonstrate on a piece
>> of paper that in a system with weak memory ordering constraints,
>> absence of a memory barrier is incorrect for any code with coupled
>> data values (e.g. a r
On Wed, Jul 13, 2011 at 8:51 AM, Paul Davis wrote:
> On Wed, Jul 13, 2011 at 9:46 AM, Olivier Guilyardi wrote:
>> On 07/13/2011 11:09 AM, Tim Blechmann wrote:
>>
>>> in fact, testing is not the best approach for verifying lock-free data
>>> structures: an implementation may work for years, if a c
On 07/13/2011 03:51 PM, Paul Davis wrote:
> On Wed, Jul 13, 2011 at 9:46 AM, Olivier Guilyardi wrote:
>> On 07/13/2011 11:09 AM, Tim Blechmann wrote:
>>
>>> in fact, testing is not the best approach for verifying lock-free data
>>> structures: an implementation may work for years, if a certain con
On 07/13/2011 11:09 AM, Tim Blechmann wrote:
> in fact, testing is not the best approach for verifying lock-free data
> structures: an implementation may work for years, if a certain condition is
> never triggered. the only reasonable way to ensure the correctness is a
> formal
> proof. unfort
On Wed, Jul 13, 2011 at 9:46 AM, Olivier Guilyardi wrote:
> On 07/13/2011 11:09 AM, Tim Blechmann wrote:
>
>> in fact, testing is not the best approach for verifying lock-free data
>> structures: an implementation may work for years, if a certain condition is
>> never triggered. the only reasonabl
>> no one can write a test case which fails when
>> memory barriers are missing in a ringbuffer implementation.
>
> That's an interesting assertion. It's kind of tempting to write some
> buggy circular buffers and test that assumption on common hardware.
in fact, testing is not the best approach
Le 13/07/11 01:56, Paul Davis a écrit :
On Tue, Jul 12, 2011 at 7:31 PM, Arnold Krille wrote:
You mean there should be a barrier to discussions about memory barriers?
No. He means that there needs to be a barrier inserted into the
discussion before its possible to move onto the next stage.
Le 13/07/11 02:08, Fred Gleason a écrit :
On Jul 12, 2011, at 19:50 05, Olivier Guilyardi wrote:
Problem is I don't have a such device at the moment.
Is your testing code online somewhere? I do have such a setup (iPad 2
provisioned as a development device in XCode), and may take a crack at
On Jul 12, 2011, at 19:50 05, Olivier Guilyardi wrote:
> Problem is I don't have a such device at the moment.
Is your testing code online somewhere? I do have such a setup (iPad 2
provisioned as a development device in XCode), and may take a crack at this.
Cheers!
|--
On Tue, Jul 12, 2011 at 7:31 PM, Arnold Krille wrote:
> You mean there should be a barrier to discussions about memory barriers?
No. He means that there needs to be a barrier inserted into the
discussion before its possible to move onto the next stage.
___
Le 13/07/11 00:23, Dan Kegel a écrit :
On Tue, Jul 12, 2011 at 2:32 PM, Olivier Guilyardi wrote:
no one can write a test case which fails when
memory barriers are missing in a ringbuffer implementation.
That's an interesting assertion. It's kind of tempting to write some
buggy circular buffe
On Tuesday 12 July 2011 22:20:48 Olivier Guilyardi wrote:
> On 07/12/2011 09:45 PM, Chris Cannam wrote:
> > Thinking it over and going back over some references and earlier
> > threads here (e.g. much earlier ones from Olivier et al) it does seem
> > that this should be enough. This particular sit
On Tue, Jul 12, 2011 at 2:32 PM, Olivier Guilyardi wrote:
> no one can write a test case which fails when
> memory barriers are missing in a ringbuffer implementation.
That's an interesting assertion. It's kind of tempting to write some
buggy circular buffers and test that assumption on common h
On 07/12/2011 11:37 PM, Chris Cannam wrote:
> On 12 July 2011 22:32, Olivier Guilyardi wrote:
>> Thing is, of every single thing that has been said on this thread about
>> memory
>> barriers and ringbuffers, no one can prove anything. On this thread, on
>> others,
>> on LAD and elsewhere. For ex
On 12 July 2011 22:32, Olivier Guilyardi wrote:
> Thing is, of every single thing that has been said on this thread about memory
> barriers and ringbuffers, no one can prove anything. On this thread, on
> others,
> on LAD and elsewhere. For example, no one can write a test case which fails
> whe
On 07/12/2011 10:36 PM, Paul Davis wrote:
> On Tue, Jul 12, 2011 at 4:20 PM, Olivier Guilyardi wrote:
>
>> Quite interestingly, I have noticed that discussions about memory barriers
>> are
>> often somehow endless. What happened in the past is that I saw countless
>> discussions about whether th
On 07/12/2011 11:07 PM, Chris Cannam wrote:
> On 12 July 2011 21:20, Olivier Guilyardi wrote:
>> Quite interestingly, I have noticed that discussions about memory barriers
>> are
>> often somehow endless. [...] So I thought, maybe there's a hidden topic
>> behind that. A "memory barrier"...
>
>
On 12 July 2011 21:36, Paul Davis wrote:
> 2) do you need memory barriers to ensure correct synchronization
> for this kind of data structure in the face of possible hardware level
> instruction reordering?
The transactional metaphor for this kind of thing seems useful -- the
id
On 12 July 2011 21:20, Olivier Guilyardi wrote:
> Quite interestingly, I have noticed that discussions about memory barriers are
> often somehow endless. [...] So I thought, maybe there's a hidden topic
> behind that. A "memory barrier"...
Indeed -- perhaps these discussions need some sort of mem
On Tue, Jul 12, 2011 at 4:20 PM, Olivier Guilyardi wrote:
> Quite interestingly, I have noticed that discussions about memory barriers are
> often somehow endless. What happened in the past is that I saw countless
> discussions about whether they are needed, whether they are not, and people
> wou
On 07/12/2011 09:45 PM, Chris Cannam wrote:
> Thinking it over and going back over some references and earlier
> threads here (e.g. much earlier ones from Olivier et al) it does seem
> that this should be enough. This particular situation isn't so
> complicated after all. I think the more I read
On 12 July 2011 13:44, Dan Muresan wrote:
> I wonder if
>
> {
> pthread_mutex_t dummy = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_lock(&dummy);
> pthread_mutex_unlock(&dummy);
> }
>
> doesn't provide a portable full memory barrier.
According to
http://pubs.opengroup.org/onlinepubs/9699919799/ba
Will this solve any of the problems you are worrying about ?
Anyway, I'm mentioning it:
http://gcc.gnu.org/projects/gomp/
--
E.R.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
> updating the read index, yes? how is that expressed as portably as
> possible? Does __sync_synchronized reliably do that? (The
> documentation is surprisingly short...)
I wonder if
{
pthread_mutex_t dummy = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&dummy);
pthread_mutex_unlock(&dummy);
On 07/12/2011 11:15 AM, Tim Blechmann wrote:
>>> using preempt_rt, the scheduling latency can be very low (like 10
>>> microseconds), if cpu frequency scaling is applied or smt/hyperthreading is
>>> enabled it can be as high as 250 microseconds (which is already quite
>>> significant, if one is usi
>> using preempt_rt, the scheduling latency can be very low (like 10
>> microseconds), if cpu frequency scaling is applied or smt/hyperthreading is
>> enabled it can be as high as 250 microseconds (which is already quite
>> significant, if one is using small signal vector sizes).
>
> That's intere
On 07/12/2011 10:27 AM, Tim Blechmann 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 use
>> 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, you can use locks as long as that's o
On 11 July 2011 21:58, Paul Davis wrote:
> On Mon, Jul 11, 2011 at 4:50 PM, Chris Cannam
> wrote:
>> Perhaps the pragmatic solution is to _lock_ the shared buffer?
>
> no, the pragmatic solution is to use memory barriers liberally applied.
Well OK, the vital library ringbuffer implementation tha
> 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 t
> 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 == sem_pos
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.
S
On Mon, Jul 11, 2011 at 6:27 PM, Robin Gareus wrote:
> On 07/12/2011 12:12 AM, Arnold Krille wrote:
>> Real-time means "as fast as possible".
>
> No, "real-time" means - _guaranteed_ to be done before time X.
> AKA. guaranteed response time.
and in an audio context, for developers of application
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
[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 recommende
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
> 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 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
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 thre
>> 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
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 t
On Mon, Jul 11, 2011 at 4:50 PM, Chris Cannam
wrote:
> On 11 July 2011 21:32, James Morris 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
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 th
On 11 July 2011 21:50, Chris Cannam wrote:
> [...] a critical section juts across the code
"just" across
Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On 11 July 2011 21:32, James Morris 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 to people like
> me
On Monday 11 July 2011, at 22.32.08, James Morris
wrote:
> On 11 July 2011 20:19, Olivier Guilyardi 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
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 g
On 11 July 2011 20:19, Olivier Guilyardi 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
non-blocking/lock-fre
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
>>
> This reordering cannot be prevented without proper synchronization. So
> my advice to anyone considering this would be to drop volatile and do
> proper synchronization at the application level (i.e. semaphores,
> since it has to work in real time).
After this whole round of discussions, it's sta
> 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 po
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 where they do not (and linux on a SPARC v9
On Jul 10, 2011, at 2:41 PM, Paul Davis wrote:
On Sun, Jul 10, 2011 at 5:14 PM, Fons Adriaensen
wrote:
On that I absolutely agree - cache coherency is the real
problem, not pipelining. The latter should in fact be
transparent from a language such as C/C++.
i may be way out of the loop, but h
Guys,
if you're writing code for your own use, and don't care about portability
or security, go ahead and use volatile as a synchronization primitive.
But if the code is going to be accepted into an open source project
that gets wide use, volatile is a bad idea. But don't take my word
for it; her
On Sun, Jul 10, 2011 at 5:14 PM, Fons Adriaensen wrote:
> On that I absolutely agree - cache coherency is the real
> problem, not pipelining. The latter should in fact be
> transparent from a language such as C/C++.
i may be way out of the loop, but having worked with some of the early
"massivel
On Sun, Jul 10, 2011 at 06:05:45PM +0300, Dan Muresan wrote:
> Ah. pthread_mutex_lock() / unlock(), as EXTERNAL functions, will never
> be optimized away or inlined. Now, being all sequence points, if you
> simply do
>
> pthread_mutex_lock();
> xval = x;
> pthread_mutex_unlock();
>
> the compile
> >> > the main problem is the lack of a memory model for multi-threaded
> >> > applications at the level of the language (c or c++). fortunately this
> >> > is about to change with c++0x and probably c1x.
> >>
> >> So in 10 years we will be able to rely on a conformant compiler being
> >> availab
On Sun, Jul 10, 2011 at 1:28 PM, Tim Blechmann wrote:
>> > the main problem is the lack of a memory model for multi-threaded
>> > applications at the level of the language (c or c++). fortunately this
>> > is about to change with c++0x and probably c1x.
>>
>> So in 10 years we will be able to rely
> > the main problem is the lack of a memory model for multi-threaded
> > applications at the level of the language (c or c++). fortunately this
> > is about to change with c++0x and probably c1x.
>
> So in 10 years we will be able to rely on a conformant compiler being
> available on all relevant
> the hardware would be allowed to reorder them ... this is the reason why mutex
> implementations involve memory barriers ...
Yes, the hardware would be allowed to reorder them, so
pthread_mutex_lock() has memory barriers. I think everyone knew that
much :)
However my point to Fons was that, bec
> Ah. pthread_mutex_lock() / unlock(), as EXTERNAL functions, will never
> be optimized away or inlined. Now, being all sequence points, if you
> simply do
>
> pthread_mutex_lock();
> xval = x;
> pthread_mutex_unlock();
>
> the compiler is not allowed to move statements out the locked section
> o
> In the example I provided the essential point is that there
> is *one* *correct* access pattern which is to read it once
> for each call to f(), to ensure that the same value is used
> everywhere in that function. Declaring this value volatile
> and taking a local copy does exactly the right thin
On Sat, Jul 09, 2011 at 04:25:22PM +0300, Dan Muresan wrote:
> >> The apps already need to do some type of synchronization internally.
> >> For example a player's disk thread, when its ringbuffer is full, needs
> >> to wait for the process thread to consume some data and thus free up
> >
> > Depen
>> The apps already need to do some type of synchronization internally.
>> For example a player's disk thread, when its ringbuffer is full, needs
>> to wait for the process thread to consume some data and thus free up
>
> Depends. If both ends are periodic processes no other synchronisation
> is re
On Sat, Jul 09, 2011 at 02:03:34AM +0300, Dan Muresan wrote:
> > Better to just follow the recommendations of the respective ABIs,
> > and put in the memory barriers for those platforms that need them,
> > like PortAudio, the linux kernel, and most other implementations
>
> The apps already need t
> Better to just follow the recommendations of the respective ABIs,
> and put in the memory barriers for those platforms that need them,
> like PortAudio, the linux kernel, and most other implementations
The apps already need to do some type of synchronization internally.
For example a player's di
Hi Paul,
On Jul 8, 2011, at 1:49 PM, Paul Davis wrote:
this is why we don't care about the types of stuff that Dan Muresan
mentioned, except to the extent that it could actually lead to the
computation of data/space available being wrong in a deeper way.
You're missing the point of what Dan wa
On Fri, Jul 8, 2011 at 8:49 PM, Paul Davis wrote:
> could be true enough, but i will be happy to fake ignorance and say i
> don't know for sure. but ...
I sure as heck don't know for sure :-)
> the whole point single reader/single writer lock-free FIFOs is that
> *synchronization doesn't matter*
On Fri, Jul 08, 2011 at 10:59:14PM +0200, Arnold Krille wrote:
> Empty for reading. Lots of space for writing.
> Its much more interesting to see what happens when the indezes cross the 2^32
> or 2^64 mark, then the write-index will be smaller then the read-index untill
> the read-index catches
On Fri, Jul 08, 2011 at 04:41:54PM -0400, Paul Davis wrote:
> On Fri, Jul 8, 2011 at 3:53 PM, Fons Adriaensen wrote:
>
> > - You can use all 2^n elements, there is no ambiguity between
> > full and empty.
>
> so what does it mean when wr_index == rd_index?
That the buffer is empty, rd_avail =
On Friday 08 July 2011 22:41:54 Paul Davis wrote:
> On Fri, Jul 8, 2011 at 3:53 PM, Fons Adriaensen wrote:
> > - You can use all 2^n elements, there is no ambiguity between
> > full and empty.
>
> so what does it mean when wr_index == rd_index?
Empty for reading. Lots of space for writing.
Its
>> > I thought a "lock-free" ring buffer was supposed to be
>> > the easy solution!
>>
>> It is... when you re-use one that's already been written and
>> debugged. ;-)
>>
>> Why not copy/paste the JACK ringbuffer (C) or even Ardours
>> (C++ Container)?
>
> Here's another C++ one, for the record
On Fri, Jul 8, 2011 at 3:29 PM, Dan Kegel wrote:
> On Fri, Jul 8, 2011 at 7:23 PM, Dan Muresan wrote:
>> (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html):
>>...
>> The only thing that volatile accomplishes is to slow down
>> properly-synchronized programs. volatile is for
On Fri, Jul 8, 2011 at 3:53 PM, Fons Adriaensen wrote:
> - You can use all 2^n elements, there is no ambiguity between
> full and empty.
so what does it mean when wr_index == rd_index?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.
On Fri, Jul 08, 2011 at 09:05:42PM +0200, Arnold Krille wrote:
> What would happen? The ringbuffer in jack is explicitely only for one-reader-
> one-writer. So in this optimization, the only participant using the read_ptr
> to do something possibly bad, is the reading participant which is curren
On Fri, Jul 8, 2011 at 7:23 PM, Dan Muresan wrote:
> (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html):
>...
> The only thing that volatile accomplishes is to slow down
> properly-synchronized programs. volatile is for signal handlers and
> interrupt handlers, not for thread
>> > > the one wrinkle in this is that in theory a compiler
>> > > could so completely reorder instructions that even the
>> > > basic assumptions that make the single
>> > > reader/single-writer ringbuffer safe would break down.
Forget about the compiler, the hardware instruction pipeline could
r
On Friday 08 July 2011 20:12:08 Gabriel M. Beddingfield wrote:
> On Friday, July 08, 2011 12:17:34 pm Fons Adriaensen wrote:
> > On Fri, Jul 08, 2011 at 09:21:55AM -0400, Paul Davis
>
> wrote:
> > > the one wrinkle in this is that in theory a compiler
> > > could so completely reorder instructions
On Fri, Jul 08, 2011 at 01:12:08PM -0500, Gabriel M. Beddingfield wrote:
> There's a remote possibility that the compiler could
> optimize this as:
>
> rb->read_ptr += n;
> rb->read_ptr &= rb->size_mask;
>
> ...and this would break the ringbuffer. I don't know if the
> `volatile` keyword
On Friday, July 08, 2011 12:17:34 pm Fons Adriaensen wrote:
> On Fri, Jul 08, 2011 at 09:21:55AM -0400, Paul Davis
wrote:
> > the one wrinkle in this is that in theory a compiler
> > could so completely reorder instructions that even the
> > basic assumptions that make the single
> > reader/single
On Fri, Jul 08, 2011 at 09:21:55AM -0400, Paul Davis wrote:
> the one wrinkle in this is that in theory a compiler could so
> completely reorder instructions that even the basic assumptions that
> make the single reader/single-writer ringbuffer safe would break down.
AFAIK nothing fatal can happe
On Thu, 2011-07-07 at 20:04 -0500, Gabriel M. Beddingfield wrote:
> On Thursday, July 07, 2011 07:50:57 pm James Morris wrote:
> > I thought a "lock-free" ring buffer was supposed to be
> > the easy solution!
>
> It is... when you re-use one that's already been written and
> debugged. ;-)
>
> W
On Fri, Jul 8, 2011 at 7:24 AM, James Morris wrote:
> While I thought my rbuf was broken I read about how lock-free code is
> not really lock-free, it just uses very fine grained locking.
> http://stackoverflow.com/questions/2528969/lock-free-multi-threading-is-for-real-threading-experts/2530082#
On 07/08/2011 02:21 PM, James Morris wrote:
> JACK's ringbuf, as most will have undoubtedly known all along, is
> faster, and the test code required 5 iterations less than when
> using my ring buf. maybe somewhere, the atomics are required?
> james.
I cannot comment on atomics op, but we have
On 8 July 2011 12:24, James Morris wrote:
> So I'd thought I'd compare the execution time of 7000 items passing
> through the two 32-item ring buffers, with the execution time 7000
> items passing though 32-item jack-ringbuffers. details to come,
> probably to throw all this out the window.
>
On 8 July 2011 01:50, James Morris wrote:
> On 7 July 2011 13:10, James Morris wrote:
>> just wondered if any more-experienced-than-i devs might comment on
>> this. written in c for c (obviously). i realize it's not portable
>> outside of GNU GCC (regarding the GCC atomic builtin funcs
>> __sync_
On 8 July 2011 02:04, Gabriel M. Beddingfield wrote:
> Why not copy/paste the JACK ringbuffer (C) or even Ardours
> (C++ Container)?
Sorry, with my warbling I forgot all about asking when the lock
function of jack ringbuffer would be used?
Cheers,
James.
On 8 July 2011 02:04, Gabriel M. Beddingfield wrote:
> On Thursday, July 07, 2011 07:50:57 pm James Morris wrote:
>> I thought a "lock-free" ring buffer was supposed to be
>> the easy solution!
>
> It is... when you re-use one that's already been written and
> debugged. ;-)
>
> Why not copy/paste
On Thursday, July 07, 2011 07:50:57 pm James Morris wrote:
> I thought a "lock-free" ring buffer was supposed to be
> the easy solution!
It is... when you re-use one that's already been written and
debugged. ;-)
Why not copy/paste the JACK ringbuffer (C) or even Ardours
(C++ Container)?
-gabr
On 7 July 2011 13:10, James Morris wrote:
> just wondered if any more-experienced-than-i devs might comment on
> this. written in c for c (obviously). i realize it's not portable
> outside of GNU GCC (regarding the GCC atomic builtin funcs
> __sync_***). meant for a single reader thread and a sing
just wondered if any more-experienced-than-i devs might comment on
this. written in c for c (obviously). i realize it's not portable
outside of GNU GCC (regarding the GCC atomic builtin funcs
__sync_***). meant for a single reader thread and a single writer
thread. comments regarding thread safety
95 matches
Mail list logo
