[gmpi] Re: multithreading host interface
- From: Martijn Sipkema <m.j.w.sipkema@xxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 10 Apr 2003 17:07:55 +0100
[...]
> atomic access means that you provide a way to warrant an exclusive access
to
> an address for Read or Write operation. I remind you that i 'm talking
about
> a uni, omni , single directionnal access : Again, i explain you : there is
> one processor which always write while the other one is always reading.
Atomic access means that you can get the current value of a memory location
and modify it atomically and _that_ is what is needed for the lock-free
ringbuffer that was discussed. Only writing to a memory location the worst
thing that can happen is that the other processor reading it may not get the
value that is in the writer's cache.
> > in addition, a member of the VST plugins list (who i will not name
> > here) worked extensively on the BeOS audio system and told me
> > privately that he has seen other SMP systems (PPC if i recall
> > correctly, but i'm not sure) with similar design issues to the
> > SPARC. i trust his judgement and recounting of these experiences.
>
> i don't want the advise of your friends, i don't want the thinking of
> students, i want an official statement saying that on SPARC system, the
> cache management cannot warrant 32bits operation. And i want that an
> electronician explain me how it is possible on 32 bits BUS (or a 64bits or
> more) architecture.
That was _not_ what we were talking about. It seems you have a different
understanding of atomic, i.e. that either the memory location is updated
or it is not, but never partially. And yes, that probably is the case when
writing a 32bit value to a properly aligned memory location on 32bit (or
higher) hardware.
> > >> and lets just note that the SPARC is not the only system with this
> > >> kind of issue.
> > >
> > >no longer the Intel based SMP system as far as i see ! :-)
> >
> > some linux kernel hackers have claimed that recent versions of the
> > linux kernel have new checks for certain kinds of x86 XMP systems in
> > which cache coherency no longer guarantees 32 bit atomicity.
>
> Linux Kernel Hacker !? what is that !? a kid who beleive that he is
> programmer ! :-))) or it's the new name for IBM employee !? :-)
You are quite annoying, no offence intended.
--ms
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
