[Stackless] The Work Plan Re: STM proposal funding

[Bengt Richter]

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 at 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