On Mon, Jul 18, 2005 at 06:54:33AM +0000, Lutz Donnerhacke wrote: > * Martin Uecker wrote: > > Lock-freie Transaktionen sind nicht neu, und auch nicht so > > unproblematisch, wie in dem Paper dargestellt. Sie skalieren nämlich > > schlecht. > > In allen Versuchen, die ich auf den Artikel aufsetzte, hatte ich weniger > Schwierigkeiten mit Skalierung als mit Locks. Dies gibt besonders deswegen, > weil Transaktionsspeicher die Abstraktion anderer Module nicht aufbricht und > ich so problemlos existierende Module zusammenwerfen konnte. Die Kombinierbarkeit scheint mir aber eher direkt aus dem für funktionale Sprachen typischen Einsatz von Higher-Order-Kombinatoren zu stammen. Es mag sein, daß Du in Deiner Applikation nicht an die Grenzen dieser Technik stößt. Es wunderte mich nur, daß bekannte Performance-Probleme (lock-freie Algorithmen werden seit mindestens zwei Jahrzehnten untersucht, siehe auch "optimistic concurrency control") nicht erwähnt werden. > > Die Implementation in einer funktionalen Sprache ist natürlich > > elegant, auch wenn mir Concurrent Haskell zu imperativ ist. > > *Lach* Ich glaube das ist der abgefahrenste Vorwurf, den man machen kann. > Nein *schüttel* ich faß' es nicht. Lachst Du über die Behauptung Concurrent Haskell wäre imperativ? Der "Concurrent"-Teil ist es schon: forkIO :: IO () -> IO () newMVar :: IO (MVar a) takeMVar :: MVar a -> IO a putMVar :: MVar a -> a -> IO () Imperativer geht es nicht mehr. Gruß, Martin -- One night, when little Giana from Milano was fast asleep, she had a strange dream.
Attachment:
signature.asc
Description: Digital signature