Hi Armin, On 04/16/2012 11:34 AM Armin Rigo wrote:
Hi Andrew,
On Sun, Apr 15, 2012 at 18:07, Andrew Francis<andrewfr_ice@yahoo.com> wrote:
So returning to the example, a programme more in the spirit of what you are doing is:
No, you are still missing my point. The goal is to work on existing stackless programs, not to write custom programs that combine "stackless" and "transaction" explicitly.
Yes, I'm saying that _any_ existing stackless-based program can be run on multiple cores (assuming common causes of conflicts are found and removed). It doesn't make much sense to go into details now because without an actual implementation we can't really know for sure what the common causes of conflicts will be --- not to mention, I don't like to talk endlessly just to try to convince people that it''s actually even possible :-)
A bientôt,
Armin.
Do you want to turn an arbitrary number of cores into a virtual uniprocessor and then use a "yield" (a la OCM) as a kind of logical critical section marker for seamless coroutine-like transfer between one section (space between yields) and another such section in another process? IOW, everything between yield executions is logically guaranteed serial within and atomic as a whole? And everything becomes a speculatively executed critical section, with potential rollback and retry? For removing "common causes of conflicts", are you thinking of static analysis to separate yield-demarked thread sections into probability-of-contention categories for different strategies of scheduling execution by actual cores? Or maybe not just static analysis, but also jit-like tracing of contention and dynamically rewriting with mutex to serialize where conflict detection/rollback/retry thrashes? Does that seem possible? How do you avoid being overprotective? E.g., if x,y,z are being written, and x,y *has* to be atomically coherent, like coordinates, but z can be any version, should the programmer write yields tightly around coherent outputs, e.g., "... yield; x=foo(); y=bar(); yield; z=baz() ..." in order not to create a non-requirement that z also be synced with x,y? Should there not be some way of programming atomicity of noun sets as well as verb sequences? E.g., what do the new concepts do for supporting programming an atomic class concept that would inherit from some base class that guarantees atomic execution of methods and thus synced access to guaranteed coherent attributes? (Which probably exists with locks etc already, but wondering what the new concepts bring to it). Really curious what you have up your sleeve. OTOH, I understand that you probably have experiments and thoughts under way that you'd rather work on than discuss or explain, so back to lurking for some decent interval ;-) Regards, Bengt Richter