[MLton] Transactions for ML

[Eric McCorkle]

On Apr 20, 2007, at 3:34 AM, Lukasz S Ziarek wrote:

> If you choose to implement contention management with locks you  
> will have to decide if you want strong atomicity (requires some  
> sort of read/write barriers on most acceses -- redudant barriers  
> can be eliminated) or weak atomicity (less "safe").

I'm assuming by strong atomicity you mean correct behavior when a  
programmer accesses data that should be accessed atomically in a non- 
atomic manner.  Every study I've seen says this does not scale  
because of the excessive barriers.  My own opinion is that it  
attempts to solve with alot of runtime overhead what is very simple  
to do by setting up your types correctly so that such behavior is  
forbidden, period.

>   I do not believe anyone has thus far done a study as to how write  
> buffer compares to updates in place

"McRT STM: A High Performance Software Transactional Memory System  
for a Multi-Core Runtime", PPoPP 2006.  They have numbers showing  
undo-logging and read versioning to be the best.  They're quieter  
about the fact that their approach requires eager conflict detection  
(and thus, requires locks).

> I dont quite follow your worry about allocating memory in a  
> scheduler context, if the scheduler was implemented in sml.

I'd be worried about this case:
* Scheduler needs to allocate memory, none available
* Garbage collector needs to run, which might require the scheduler  
to switch some threads

-- 
Eric McCorkle
Brown University
CS Graduate Student



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20070420/48687473/attachment.html