Hi John,
Just wondering: What is too slow to support a shared heap? Two times
slower? Ten times?
It is valuable to be able to do some multithreading no matter what the
processing speed becomes. Also from an academic point of view. It made
sense more than a decade ago, why not now?
It all depends on the application that one wants to devise. So just
make it an optional feature.
I am not against message passing, but it makes a lot of sense to have
some parallelism along the lines of good old {P} and {I}. For no other
reason than that explicit message passing is not what makes a
functional language stand out.
I am sure that you could have a basic setup running within a month (I
don't want to pressure you).
best regards,
Marco
On May 8, 2009, at 5:41 PM, John van Groningen wrote:
Parnell Flynn wrote:
Are there any plans to add any of the features presented in Pascal
Serrarens's paper? Any plans to bring the Concurrent back to
Concurrent
CLEAN?
We plan to make the generated code and runtime system thread safe.
This
makes it possible to create threads with separate heaps and stacks.
We would also like to have threads that share the heap. Unfortunately
the synchronization primitives supported by current processors are so
slow that these slow down the execution of programs too much.
Kind regards,
John van Groningen
_______________________________________________
clean-list mailing list
[email protected]
http://mailman.science.ru.nl/mailman/listinfo/clean-list
_______________________________________________
clean-list mailing list
[email protected]
http://mailman.science.ru.nl/mailman/listinfo/clean-list
