On Sun, Apr 06, 2003 at 01:10:17PM +0200, Ingo Oeser wrote:
> > Sure, it will only work on architectures where 32bit reads and writes are
> > atomic.
>
> That is not even true on all ix86 machines. At least I've seen
> special memory ordering barriers used in the kernel for newer
> ix86 machines
Hi there,
On Sat, Apr 05, 2003 at 06:08:51PM +0100, Steve Harris wrote:
> On Sat, Apr 05, 2003 at 06:15:09 +0200, Ingo Oeser wrote:
> > Now make that thread-safe and esp. thread-safe on an architecture
> > with weak memory ordering and all the fun stuff.
>
> Sure, it will only work on architectur
On Sat, Apr 05, 2003 at 06:15:09 +0200, Ingo Oeser wrote:
> Now make that thread-safe and esp. thread-safe on an architecture
> with weak memory ordering and all the fun stuff.
Sure, it will only work on architectures where 32bit reads and writes are
atomic.
> If you have that all working and lo
Hi,
On Sat, Apr 05, 2003 at 01:08:30PM +0100, Steve Harris wrote:
> There are many cases in audio software when you are only concerned with
> reading single values at a time from the fifo and relative delays, then
> its much simpler [from memory, syntax might be wrong]:
>
> unsigned int siz
There are many cases in audio software when you are only concerned with
reading single values at a time from the fifo and relative delays, then
its much simpler [from memory, syntax might be wrong]:
unsigned int size = some_power_of_two
unsigned int write_ptr = 0
float buff
On Fri, Apr 04, 2003 at 08:00:36PM +0100, Bob Ham wrote:
> On Thu, 2003-04-03 at 21:14, rm wrote:
>
> > below is what i use (i think it works). the primary thing to notice
> > is that readers and writers are kept in line by the atomicity of
> > integer assignment (though in general, we should prob
>> >Also, several people have referred to the atomicity of int/pointer
>> >read/write. This is news to me - can someone point me at the spec for this
>?
>>
>> its an architecture-specific issue. its not true on SPARCs and on some
>> NUMA systems. it has nothing to do with a language per se.
>
>Is
> >Also, several people have referred to the atomicity of int/pointer
> >read/write. This is news to me - can someone point me at the spec for this?
>
> its an architecture-specific issue. its not true on SPARCs and on some
> NUMA systems. it has nothing to do with a language per se.
Is it reall
>OK, I haven't been programming much lately, but when did I miss atomic_t
>becoming a part of any C standard?
its not. its a type derived from the kernel headers, which also
defines some basic operations on them. for most common architectures,
they resolve to integer read/write.
>Also, several pe
> Attached is the fifo I've had banging about. It uses atomic_t.
OK, I haven't been programming much lately, but when did I miss atomic_t
becoming a part of any C standard?
Also, several people have referred to the atomicity of int/pointer
read/write. This is news to me - can someone point me
On Fri, 2003-04-04 at 20:00, Bob Ham wrote:
> if (atomic_read (&lff->write_index) >= lff->size)
> atomic_set (&lff->write_index, -1);
Oops.. should be
atomic_set (&lff->write_index, 0);
--
Bob Ham <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally sign
On Thu, 2003-04-03 at 21:14, rm wrote:
> below is what i use (i think it works). the primary thing to notice
> is that readers and writers are kept in line by the atomicity of
> integer assignment (though in general, we should probably declare them
> atomic_t or something).
Attached is the fifo I
On Fri, Apr 04, 2003 at 07:48:20AM -0500, Paul Davis wrote:
> just for completeness sake, this isn't really true. the atomicness of
> int writes/reads isn't central. what is central is (as you noted) the
> single (group of synchronous) reader(s) and single (group of
> synchronous) writer(s), and th
On Fri, Apr 04, 2003 at 07:48:20 -0500, Paul Davis wrote:
> there is one aspect of the LFRB that bothers me. as has been explained
> many times, the monotonic motion of the read/write pointers is
> key. but when one the reader/writer moves the pointer to the end of
> the buffer and wraps it around,
On Thu, 3 Apr 2003, Tim Hockin wrote:
> > > i remember i have read a statement about a lock free ringbuffer
> > > implemented in C somewhere.
> >
> > courtesy of paul davis:
> >
> > you should use a lock free ringbuffer. we will be adding example code
> > to the example-clients directory
>below is what i use (i think it works). the primary thing to notice
>is that readers and writers are kept in line by the atomicity of
>integer assignment (though in general, we should probably declare them
>atomic_t or something).
just for completeness sake, this isn't really true. the atomicness
On Fri, Apr 04, 2003 at 07:27:57AM -0500, rm wrote:
> On Fri, Apr 04, 2003 at 05:03:54PM +0200, [EMAIL PROTECTED] wrote:
>
> so before a writer puts something on the queue to the RT thread it
> first dequeues everything returning from the RT thread, and then
> enqueues its item. since these items
On Fri, Apr 04, 2003 at 05:03:54PM +0200, [EMAIL PROTECTED] wrote:
> The problem i have with the current ringbuffer, is that it does not
> solve the synchronization of the non realtime thread to the realtime
> thread. what should be done when you cant write to the buffer ?
> usleep( a_sensible_val
On Thu, Apr 03, 2003 at 03:14:53PM -0500, rm wrote:
> On Thu, Apr 03, 2003 at 11:31:29AM -0800, Tim Hockin wrote:
> > > courtesy of paul davis:
> > >
> > > you should use a lock free ringbuffer. we will be adding example code
> > > to the example-clients directory soon. existing code i
On Thu, Apr 03, 2003 at 11:31:29AM -0800, Tim Hockin wrote:
> > courtesy of paul davis:
> >
> > you should use a lock free ringbuffer. we will be adding example code
> > to the example-clients directory soon. existing code is in ardour's
> > source base (for C++). the example code
I have a copy. I'll attach it.
On Thu 03/04/2003 11:31:29, Tim Hockin wrote:
> > > i remember i have read a statement about a lock free ringbuffer
> > > implemented in C somewhere.
> >
> > courtesy of paul davis:
> >
> > you should use a lock free ringbuffer. we will be adding example co
> > i remember i have read a statement about a lock free ringbuffer
> > implemented in C somewhere.
>
> courtesy of paul davis:
>
> you should use a lock free ringbuffer. we will be adding example code
> to the example-clients directory soon. existing code is in ardour's
> source
22 matches
Mail list logo
