Comments on: Fremtidige løfter http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/ om livet som .net utvikler Wed, 16 May 2012 21:05:45 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Vidar http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/#comment-102637 Vidar Mon, 09 Aug 2010 08:37:31 +0000 http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/#comment-102637 :) Glimdrende, den implementasjonen vil nok vere ein god del meir cpu-effektiv, siden tråden nå ikkje "våkner" opp kvart 10ms for å sjekke om den har fått noge data. Men både med denne implementasjonen og den originale så må ein være bevisst at ein kan havne i ein deadlock-situasjon, der kode som venter på Promise blir ståande og vente i all evighet. Enten fordi ein har "glemt" å faktisk gi data til Promise, eller fordi ein av trådane har kasta ein exception før den fekk gitt ein verdi. Eg har hatt eit par sånne bugs og det som skjer er at hovedtråden bare står og spinner mens den venter på at alle trådane skal bli ferdig. Eg jobber med ein ganske massiv parallell kodebase nå, og har hatt eit par tilsvarende Heisenbugs. Heisenbugs fordi det er ikkje alltid trådane som skal sende ut verdi går i Exception. ;) :) Glimdrende, den implementasjonen vil nok vere ein god del meir cpu-effektiv, siden tråden nå ikkje “våkner” opp kvart 10ms for å sjekke om den har fått noge data.
Men både med denne implementasjonen og den originale så må ein være bevisst at ein kan havne i ein deadlock-situasjon, der kode som venter på Promise blir ståande og vente i all evighet. Enten fordi ein har “glemt” å faktisk gi data til Promise, eller fordi ein av trådane har kasta ein exception før den fekk gitt ein verdi. Eg har hatt eit par sånne bugs og det som skjer er at hovedtråden bare står og spinner mens den venter på at alle trådane skal bli ferdig. Eg jobber med ein ganske massiv parallell kodebase nå, og har hatt eit par tilsvarende Heisenbugs. Heisenbugs fordi det er ikkje alltid trådane som skal sende ut verdi går i Exception. ;)

]]> By: Torbjørn http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/#comment-102636 Torbjørn Mon, 09 Aug 2010 08:18:03 +0000 http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/#comment-102636 Takk, Vidar. Her er Promise<T> implementert med AutoResetEvent. Den fungerer nå litt anderledes, og kan gjenbrukes. Den forventer nå et kall til Deliver for hver gang man aksesserer Value. Vil du ha en versjon som "leveres" én gang men kan aksesseres mange ganger kan du kombinere implementasjonen av min orginale Promise<T> med denne. Kommer an på hvordan man forventer at den skal fungere.. <tt><pre> public class Promise<T> { private T _value; private AutoResetEvent _delivered = new AutoResetEvent(false); public T Value { get { _delivered.WaitOne(); return _value; } } public void Deliver(T value) { _value = value; _delivered.Set(); } } </pre></tt> Takk, Vidar. Her er Promise implementert med AutoResetEvent. Den fungerer nå litt anderledes, og kan gjenbrukes. Den forventer nå et kall til Deliver for hver gang man aksesserer Value. Vil du ha en versjon som “leveres” én gang men kan aksesseres mange ganger kan du kombinere implementasjonen av min orginale Promise med denne. Kommer an på hvordan man forventer at den skal fungere..

    public class Promise
    {
        private T _value;
        private AutoResetEvent _delivered = new AutoResetEvent(false);
        public T Value
        {
            get
            {
                _delivered.WaitOne();
                return _value;
            }
        }
        public void Deliver(T value)
        {
            _value = value;
            _delivered.Set();
        }
    }

]]> By: Anders Norås http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/#comment-102633 Anders Norås Mon, 09 Aug 2010 06:56:23 +0000 http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/#comment-102633 Fin fin post Torbjørn. Jeg tror den mest kjente implementasjonen av future-patternet på .NET-plattformen må være NHibernate.Futures, men også LINQs defered execution er en variant av dett. I en ORM er det massevis av sense i å benytte slike patterns, slik at rammeverket selv kan optimere spørring mm. Jeg likte særlig godt at du benyttet delegates fremfor å gå den "magiske" AOP-veien med implementasjonen din. Ved å bruke delegates eksplisitt blir det lettere å lese koden og man vet at man ikke har noen garanti for at en delegate eksekveres umiddelbart dersom man har noen år med C# i ryggen. Selvom Clojure-eksemplet, og mange andre eksempler man ser, fokuserer på multi-threading, har egentlig dette patternet lite å gjøre med multi-threading. Ta NH-eksemplet jeg refererte til. NH bruker futures for å "lære" mer om hva brukeren faktisk har til hensikt å gjøre slik at databasespørringene blir mer effektive. (Se linken over for kodeeksempeler). Tenk også en eller annen form for aggregeringskode: IProducer p = new Producer(); IFuture c = p.Count(); IFuture maxl = p.Max(x => x.Length); p.Produce(strings); Console.WriteLine("Actual count: " + c.Value); Console.WriteLine("Actual max length: " + maxl.Value); Her brukes futures for deklare antall og makslengde-aggregatorer før man jobber med data. Selve aggregeringen gjøres først når man leser av verdien. Dette er tilsavarende hvordan deferred execution i LINQ fungerer. Der kan man deklarere en spørring, men denne utføres ikke før man prøver å lese resultatet. Fin fin post Torbjørn.

Jeg tror den mest kjente implementasjonen av future-patternet på .NET-plattformen må være NHibernate.Futures, men også LINQs defered execution er en variant av dett. I en ORM er det massevis av sense i å benytte slike patterns, slik at rammeverket selv kan optimere spørring mm.

Jeg likte særlig godt at du benyttet delegates fremfor å gå den “magiske” AOP-veien med implementasjonen din. Ved å bruke delegates eksplisitt blir det lettere å lese koden og man vet at man ikke har noen garanti for at en delegate eksekveres umiddelbart dersom man har noen år med C# i ryggen.

Selvom Clojure-eksemplet, og mange andre eksempler man ser, fokuserer på multi-threading, har egentlig dette patternet lite å gjøre med multi-threading. Ta NH-eksemplet jeg refererte til. NH bruker futures for å “lære” mer om hva brukeren faktisk har til hensikt å gjøre slik at databasespørringene blir mer effektive. (Se linken over for kodeeksempeler).
Tenk også en eller annen form for aggregeringskode:

IProducer p = new Producer();
IFuture c = p.Count();
IFuture maxl = p.Max(x => x.Length);
p.Produce(strings);
Console.WriteLine(“Actual count: ” + c.Value);
Console.WriteLine(“Actual max length: ” + maxl.Value);

Her brukes futures for deklare antall og makslengde-aggregatorer før man jobber med data. Selve aggregeringen gjøres først når man leser av verdien. Dette er tilsavarende hvordan deferred execution i LINQ fungerer. Der kan man deklarere en spørring, men denne utføres ikke før man prøver å lese resultatet.

]]> By: Vidar http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/#comment-102631 Vidar Mon, 09 Aug 2010 06:28:42 +0000 http://blog.kjempekjekt.com/2010/08/08/fremtidige-lfter/#comment-102631 Tør eg foreslå å bruke http://msdn.microsoft.com/en-us/library/system.threading.autoresetevent.aspx istedet for while(..) sleep(). ;) Etter å ha oppdaga den prøver eg sjøl i mest mulig grad å bruke den istedet når eg lager parallell kode. Når det gjelder Future så vil Async-cache gi deg noge av den samme funksjonaliteten, dog ikkje heilt samme, men eg anbefaler deg å ta ein kikk: http://blogs.msdn.com/b/pfxteam/archive/2010/04/23/10001621.aspx Og TPL + extensions extras e virkelig kult! ;) Tør eg foreslå å bruke http://msdn.microsoft.com/en-us/library/system.threading.autoresetevent.aspx istedet for while(..) sleep(). ;) Etter å ha oppdaga den prøver eg sjøl i mest mulig grad å bruke den istedet når eg lager parallell kode.

Når det gjelder Future så vil Async-cache gi deg noge av den samme funksjonaliteten, dog ikkje heilt samme, men eg anbefaler deg å ta ein kikk:
http://blogs.msdn.com/b/pfxteam/archive/2010/04/23/10001621.aspx

Og TPL + extensions extras e virkelig kult! ;)

]]>