[Openmcl-devel] Clozure-powered PEAP project proposal and question to Gary
Gary Byers
gb at clozure.com
Tue Oct 5 08:50:16 PDT 2010
On Tue, 5 Oct 2010, Yakov Zaytsev wrote:
> Let me know if you are interested in the project in order to get more people
> involved. At the moment I'm the only programmer.
> http://www.omappedia.org/wiki/PEAP_Projects#Feasible_Mobile_Augmented_Reali
> ty_Toolbox
>
> Gary, could you please tell us more about SMP support on ARM at the present
> state of the port?
>
>
It basically runs (about as well as it does elsewhere) on the only multicore
ARM machine that I have (an Nvidia Tegra 2 development system.)
I suspect that a lot of memory-synchronization primitives really need to use
dmb ("data memory barrier") instructions to keep all cores' view of memory
consistent. dmb is only implemented on ARMv7; it's not clear whether it's
preferable to test some bit somewhere ("this is a multicore v7 machine") and
branch around the dmb or to just requre ARMv7 and execute them unconditionally.
(The lisp is nominally supposed to run on some ARMv6T2 machines, but it's
not clear that there are enough such machines to justify that.) Since those
dmb instructions aren't used, there's a non-zero chance that some synchronization
primitive could misbehave, and that chance generally increases under higher
load.
There are likely issues related to pc-lusering (ensuring that when a thread
is interrupted or suspended in the middle of some otherwise atomic operations
that those operations either complete or are restarted.) That code is complicated
and machine-dependent and I generally only trust it after I've stepped through
it several times in GDB, and it can be hard to reliably exercise that code.
Both of these things are real problems; it's hard to say how great the
possibility of running into either is besides "it's something greater than 0%,
and that possibility increases with more thread activity and concurrency."
I don't know of other problems that're thread- or SMP-specific, but wouldn't
be totally shocked if such problems existed. I wouldn't be too shocked if
other ARM-specific bugs - compiler bugs, runtime bugs, other bugs - were
present as well. On the one hand, I think that the ARM port's gotten fairly
usable fairly quickly and I'm generally pleased with it; on the other hand,
it's very new and hasn't been widely used. The best thing for it at this
point would be for people to use it in real projects, and it's probably right
around the point where that isn't a total waste of time.
More information about the Openmcl-devel
mailing list