GÜNCELLEME

C # 6'dan itibaren, bu sorunun cevabı :

SomeEvent?.Invoke(this, e);

Aşağıdaki tavsiyeleri sık sık duyuyorum / okuyorum:

Bir etkinliği kontrol etmeden nullve tetiklemeden önce her zaman bir kopyasını oluşturun . Bu, etkinliğin nullnull olup olmadığını kontrol ettiğiniz yerle olayı tetiklediğiniz yer arasındaki noktada gerçekleşme olasılığını ortadan kaldırır :

// Copy the event delegate before checking/calling
EventHandler copy = TheEvent;

if (copy != null)
    copy(this, EventArgs.Empty); // Call any handlers on the copied list

Güncelleme : Optimizasyonları okuduğumda bunun da olay üyesinin değişken olmasını gerektirebileceğini düşündüm, ancak Jon Skeet cevabında CLR'nin kopyayı optimize etmediğini belirtti.

Ancak bu arada, bu sorunun ortaya çıkması için başka bir iş parçacığının böyle bir şey yapmış olması gerekir:

// Better delist from event - don't want our handler called from now on:
otherObject.TheEvent -= OnTheEvent;
// Good, now we can be certain that OnTheEvent will not run...

Gerçek dizi bu karışım olabilir:

// Copy the event delegate before checking/calling
EventHandler copy = TheEvent;

// Better delist from event - don't want our handler called from now on:
otherObject.TheEvent -= OnTheEvent;    
// Good, now we can be certain that OnTheEvent will not run...

if (copy != null)
    copy(this, EventArgs.Empty); // Call any handlers on the copied list

OnTheEventYazarın aboneliği iptal edildikten sonra devam eden nokta , yine de bunun olmasını önlemek için özel olarak aboneliği iptal edilir. Elbette gerçekten ihtiyaç duyulan şey, uygun senkronizasyona sahip özel bir etkinlik uygulamasıdır.add ve removeerişimcilerde . Ayrıca, bir olay tetiklenirken bir kilit tutulursa olası kilitlenme sorunu vardır.

Peki bu Kargo Kült Programlama mı? Öyle görünüyor - bir çok insan kodlarını birden fazla iş parçacığından korumak için bu adımı atmalı, gerçekte olayların çok iş parçacıklı bir tasarımın parçası olarak kullanılmadan önce bundan daha fazla bakım gerektirdiğini düşünüyorum. . Sonuç olarak, bu ek bakımı almayan insanlar da bu tavsiyeyi görmezden gelebilir - bu sadece tek iş parçacıklı programlar için bir sorun değildir ve aslında,volatile çoğu çevrimiçi örnek kodun , tavsiyenin hiç etkisi.

(Ve delegate { }üye beyanında boş olanı atamak çok daha kolay değil mi?null ilk etapta mi?)

Güncellenmiş:Açık değilse, her koşulda null referans istisnasından kaçınmak için tavsiyenin niyetini kavradım. Demek istediğim, bu özel null referans istisnasının yalnızca olaydan başka bir iş parçacığı çıkarması durumunda ortaya çıkabilir ve bunu yapmanın tek nedeni, bu olay aracılığıyla başka teknik çağrıların alınmamasını sağlamaktır. . Bir yarış koşulunu gizleyecektiniz - ortaya çıkarmak daha iyi olurdu! Bu boş istisna, bileşeninizin kötüye kullanımını tespit etmeye yardımcı olur. Bileşeninizin kötüye kullanıma karşı korunmasını istiyorsanız, WPF örneğini takip edebilirsiniz - iş parçacığının yapıcısında depolanıp başka bir iş parçacığı doğrudan bileşeninizle etkileşime girmeye çalışırsa bir istisna atabilirsiniz. Ya da gerçekten güvenli bir bileşen uygulayın (kolay bir iş değil).

Bu yüzden sadece bu kopyalama / kontrol deyimini yapmanın, kodunuza karışıklık ve gürültü ekleyerek kargo kült programlama olduğunu iddia ediyorum. Aslında diğer ipliklere karşı korunmak çok daha fazla iş gerektirir.

Eric Lippert'in blog gönderilerine yanıt olarak güncelleme:

Bu yüzden olay işleyicileri hakkında kaçırdığım önemli bir şey var: "olay işleyicileri, abonelik iptal edildikten sonra bile çağrılması karşısında sağlam olmalı" ve bu nedenle yalnızca olayın olasılığını önemsememiz gerekiyor. delege olmak null. Olay işleyicileri için bu gereksinim herhangi bir yerde belgelenmiş mi?

Ve böylece: "Bu sorunu çözmenin başka yolları da var; örneğin, işleyicinin hiçbir zaman kaldırılmamış boş bir eylem için başlatılması. Ancak boş bir denetim yapmak standart modeldir."

Öyleyse sorumun kalan kısmı, "standart kalıp" için neden açık-boş-kontrol? Boş delege atayan alternatif, yalnızca = delegate {}olay bildirimine eklenmeyi gerektirir ve bu, olayın yapıldığı her yerden küçük kokmuş tören yığınlarını ortadan kaldırır. Boş delegenin somutlaştırılması ucuz olduğundan emin olmak kolay olacaktır. Yoksa hala bir şey mi kaçırıyorum?

Şüphesiz (Jon Skeet'in önerdiği gibi) bu, 2005'te yapması gerektiği gibi, ölmemiş olan sadece .NET 1.x tavsiyesi olmalı?

Durum nedeniyle, JIT'in ilk bölümde bahsettiğiniz optimizasyonu yapmasına izin verilmiyor. Bunun bir hayalet olarak ortaya çıktığını biliyorum, ama geçerli değil. (Bir süre önce Joe Duffy veya Vance Morrison ile kontrol ettim; hangisini hatırlayamıyorum.)

Uçucu değiştirici olmadan, alınan yerel kopyanın eski olması mümkündür, ancak hepsi bu. Bir neden olmaz NullReferenceException.

Ve evet, kesinlikle bir yarış durumu var - ama her zaman olacak. Kodu sadece şu şekilde değiştirdiğimizi varsayalım:

TheEvent(this, EventArgs.Empty);

Şimdi delege için çağrı listesinde 1000 giriş bulunduğunu varsayalım. Başka bir iş parçacığı listenin sonuna yakın bir işleyiciyi iptal etmeden önce, listenin başlangıcındaki eylemin gerçekleştirilmiş olması mümkündür. Ancak, bu işleyici yeni bir liste olacağından yürütülmeye devam edecektir. (Delegeler değişmez.) Görebildiğim kadarıyla bu kaçınılmaz.

Boş bir delege kullanmak kesinlikle geçersizlik kontrolünden kaçınır, ancak yarış koşulunu düzeltmez. Ayrıca, değişkenin her zaman en son değerini "göreceğinizi" garanti etmez.

Bunu yapmanın uzatma yöntemine giden birçok insan görüyorum ...

public static class Extensions   
{   
  public static void Raise<T>(this EventHandler<T> handler, 
    object sender, T args) where T : EventArgs   
  {   
    if (handler != null) handler(sender, args);   
  }   
}

Bu, etkinliği yükseltmek için daha iyi bir sözdizimi sağlar ...

MyEvent.Raise( this, new MyEventArgs() );

Ayrıca yöntem çağrısı zamanında yakalandığından yerel kopyayı ortadan kaldırır.

"Neden 'açık' null-standart 'kalıbı kontrol ediyor?"

Bunun sebebinin sıfır kontrolünün daha performanslı olabileceğinden şüpheleniyorum.

Oluşturulduklarında etkinliklerinize her zaman boş bir temsilci abone olursanız, bazı ek yükler olacaktır:

• Boş delege oluşturma maliyeti.
• Onu içerecek bir delege zinciri oluşturma maliyeti.
• Etkinlik her başlatıldığında anlamsız delege çağırmanın maliyeti.

(Kullanıcı Arabirimi denetimlerinin çoğu zaman hiç abone olmadıkları çok sayıda etkinliğe sahip olduğunu unutmayın. Her etkinliğe kukla bir abone oluşturmak ve daha sonra çağırmak önemli bir performans isabeti olacaktır.)

Abone-boş-delege yaklaşımının etkisini görmek için bazı üstünkörü performans testleri yaptım ve işte sonuçlarım:

Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      432ms
OnClassicNullCheckedEvent took: 490ms
OnPreInitializedEvent took:     614ms <--
Subscribing an empty delegate to each event . . .
Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      674ms
OnClassicNullCheckedEvent took: 674ms
OnPreInitializedEvent took:     2041ms <--
Subscribing another empty delegate to each event . . .
Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      2011ms
OnClassicNullCheckedEvent took: 2061ms
OnPreInitializedEvent took:     2246ms <--
Done

Sıfır veya bir abone durumunda (etkinliklerin bol olduğu UI denetimleri için ortaktır), boş bir delege ile önceden başlatılan etkinliğin oldukça yavaş olduğunu (50 milyondan fazla yineleme ...) unutmayın.

Daha fazla bilgi ve kaynak kodu için, bu sorunun sorulmasından bir gün önce yayınladığım .NET Olay çağırma iş parçacığı güvenliği hakkındaki bu blog gönderisini ziyaret edin (!)

(Test kurulumum kusurlu olabilir, bu nedenle kaynak kodunu indirip kendiniz inceleyebilirsiniz. Herhangi bir geri bildirim çok takdir edilmektedir.)

Bu okuma gerçekten keyif aldım - değil! Olaylar adı verilen C # özelliği ile çalışmak için ihtiyacım olmasına rağmen!

Bunu derleyicide neden düzeltmiyorsunuz? Bu yazıları okuyan MS kullanıcıları olduğunu biliyorum, bu yüzden lütfen bunu alevlendirmeyin!

1 - Null sorunu ) Neden ilk etapta null yerine boş. Boş kontrol için veya = delegate {}bildirime a yapıştırmak için kaç satır kod kaydedilebilir ? Derleyici Boş durumda işlemesine izin verin, IE hiçbir şey yapmayın! Her şey etkinliğin yaratıcısı için önemliyse, .Empty'yi kontrol edebilir ve ilgilendiklerini yapabilirler! Aksi takdirde tüm null çekler / delege ekler sorunun etrafında kesmek vardır!

Dürüst olmak gerekirse, her olayla bunu yapmaktan bıktım - aka boilerplate kodu!

public event Action<thisClass, string> Some;
protected virtual void DoSomeEvent(string someValue)
{
  var e = Some; // avoid race condition here! 
  if(null != e) // avoid null condition here! 
     e(this, someValue);
}

2 - yarış koşulu sorunu ) Eric'in blog gönderisini okudum, H (işleyici) dereferences kendisini ele almalıdır, ancak olay değişmez / iş parçacığı güvenli hale getirilemez mi? IE, oluşturulmasında bir kilit bayrağı ayarlar, böylece her çağrıldığında, yürütme sırasında ona tüm aboneliği ve aboneliği engeller?

Sonuç ,

Günümüz dillerinin bizim için bu gibi sorunları çözmesi gerekmez mi?

İle C'nin 6. üstünde ve kod yeni kullanılarak basitleştirilmiş olabilir ?.gibi operatörünü:

TheEvent?.Invoke(this, EventArgs.Empty);

İşte MSDN belgeleri.

C # üzerinden CLR kitabındaki Jeffrey Richter'e göre , doğru yöntem:

// Copy a reference to the delegate field now into a temporary field for thread safety
EventHandler<EventArgs> temp =
Interlocked.CompareExchange(ref NewMail, null, null);
// If any methods registered interest with our event, notify them
if (temp != null) temp(this, e);

Çünkü bir referans kopyasını zorlar. Daha fazla bilgi için kitaptaki Etkinlik bölümüne bakın.

Olay işleyicilerinin abonelikleri kaldırıldıktan sonra yürütülmediğinden emin olmak için bu tasarım desenini kullanıyorum. Performans profillemeyi denemememe rağmen şu ana kadar oldukça iyi çalışıyor.

private readonly object eventMutex = new object();

private event EventHandler _onEvent = null;

public event EventHandler OnEvent
{
  add
  {
    lock(eventMutex)
    {
      _onEvent += value;
    }
  }

  remove
  {
    lock(eventMutex)
    {
      _onEvent -= value;
    }
  }

}

private void HandleEvent(EventArgs args)
{
  lock(eventMutex)
  {
    if (_onEvent != null)
      _onEvent(args);
  }
}

Bu günlerde çoğunlukla Android için Mono ile çalışıyorum ve Etkinliği arka plana gönderildikten sonra bir Görünümü güncellemeye çalıştığınızda Android bunu beğenmiyor gibi görünüyor.

Bu uygulama belirli bir operasyon sırasını uygulamakla ilgili değildir. Aslında null referans istisnasından kaçınmakla ilgilidir.

Yarış koşulunu değil, boş referans istisnasını önemseyen insanların arkasındaki mantık, bazı derin psikolojik araştırmalar gerektirecektir. Ben boş referans sorunu düzeltmek çok daha kolay olduğu gerçeği ile ilgili bir şey olduğunu düşünüyorum. Bu sorun çözüldükten sonra, kodlarına büyük bir "Görev Tamamlandı" afişi asarlar ve uçuş kıyafetlerini çıkartırlar.

Not: yarış koşulunun düzeltilmesi, muhtemelen işleyicinin çalışıp çalışmayacağı konusunda eşzamanlı bir bayrak izi kullanmayı içerir

Bu yüzden partiye biraz geç kaldım. :)

Abonesi olmayan olayları temsil etmek için null nesne kalıbı yerine null nesnenin kullanımına gelince, bu senaryoyu dikkate alın. Bir etkinliği çağırmanız gerekir, ancak nesneyi (EventArgs) oluşturmak önemsizdir ve genel durumda etkinliğinizin abonesi yoktur. Argümanları oluşturmak ve olayı çağırmak için işleme çabası göstermeden önce, herhangi bir aboneniz olup olmadığını kontrol etmek için kodunuzu optimize edebilmeniz sizin için yararlı olacaktır.

Bunu göz önünde bulundurarak, bir çözüm "iyi, sıfır abone null ile temsil edilir" demektir. Sonra pahalı işleminizi yapmadan önce null kontrolünü yapın. Bunu yapmanın başka bir yolunun Delege türünde bir Count özelliğine sahip olacağını varsayalım, bu yüzden pahalı işlemi yalnızca myDelegate.Count> 0 ise gerçekleştirirsiniz. ve aynı zamanda bir NullReferenceException özelliğine neden olmadan çağrılabilme özelliğine de sahiptir.

Bununla birlikte, delegeler referans türleri olduğu için null olmalarına izin verildiğini unutmayın. Belki de bu gerçeği kapakların altında saklamanın ve yalnızca olaylar için null nesne modelini desteklemenin iyi bir yolu yoktu, bu yüzden alternatif geliştiricileri hem null hem de sıfır abone için kontrol etmeye zorlamış olabilir. Mevcut durumdan bile daha çirkin olurdu.

Not: Bu saf spekülasyon. .NET dilleri veya CLR ile ilgilenmiyorum.

tek iş parçacıklı aplikatörler için, bu bir sorun değildir düzeltir.

Ancak, olayları ortaya çıkaran bir bileşen oluşturuyorsanız, bileşeninizin bir tüketicisinin çok iş parçacığına gitmeyeceğine dair bir garanti yoktur, bu durumda en kötüsüne hazırlanmanız gerekir.

Boş temsilci kullanmak sorunu çözer, ancak etkinliğe yapılan her çağrıda performansa neden olur ve muhtemelen GC sonuçları olabilir.

Bunun gerçekleşmesi için tüketici aboneliğini iptal etmekte haklısınız, ancak geçici kopyayı geçtiyse, zaten iletilen iletiyi düşünün.

Geçici değişkeni kullanmazsanız ve boş temsilci kullanmazsanız ve biri abonelikten çıkarsa, ölümcül olan bir boş başvuru istisnası alırsınız, bu yüzden maliyetin buna değer olduğunu düşünüyorum.

Bunu gerçekten çok fazla sorun olarak görmedim, çünkü genellikle yalnızca yeniden kullanılabilir bileşenlerimdeki statik yöntemlerde (vb.) Bu tür potansiyel iş parçacığı kötülüğüne karşı koruma sağlıyorum ve statik olaylar yapmıyorum.

Yanlış mı yapıyorum?

Tüm etkinliklerinizi hazırlayın ve yalnız bırakın. Delegate sınıfının tasarımı, bu yayının son paragrafında açıklayacağım gibi, başka herhangi bir kullanımı doğru bir şekilde kullanamaz.

Her şeyden önce, olay işleyicilerinizin bildirime yanıt verip vermemeye / nasıl yanıt vereceğine dair senkronize bir karar vermesi gerektiğinde bir olay bildirimini durdurmaya çalışmanın bir anlamı yoktur .

Bildirilebilecek her şey bildirilmelidir. Olay işleyicileriniz bildirimleri düzgün bir şekilde işliyorsa (yani yetkili bir başvuru durumuna erişimleri varsa ve yalnızca uygun olduğunda yanıt veriyorlarsa), bunları istedikleri zaman bilgilendirmek ve doğru şekilde yanıt vereceğine güvenmek iyi olacaktır.

Bir işleyicinin bir olayın meydana geldiği konusunda bilgilendirilmemesi gereken tek şey, olayın gerçekleşmediği zamandır! Bu nedenle, bir işleyicinin bilgilendirilmesini istemiyorsanız, olayları oluşturmayı durdurun (yani, denetimi devre dışı bırakın veya olayı ilk başta tespit etmek ve var olandan sorumlu kılmak için).

Dürüst olmak gerekirse, Delege sınıfının kurtarılamaz olduğunu düşünüyorum. Bir MulticastDelegate ile birleşme / geçiş çok büyük bir hataydı, çünkü etkinliğin (yararlı) tanımını tek bir anda gerçekleşen bir şeyden bir zaman aralığında gerçekleşen bir şeye etkili bir şekilde değiştirdi. Böyle bir değişiklik, mantıksal olarak tek bir anı içine geri daraltabilen bir senkronizasyon mekanizması gerektirir, ancak MulticastDelegate böyle bir mekanizmadan yoksundur. Senkronizasyon, olayın gerçekleştiği tüm zaman aralığını veya anı kapsamalıdır, böylece bir uygulama bir olayı işlemeye başlamak için senkronize edilmiş bir karar verdiğinde, olayı tamamen (işlemsel) işlemeyi bitirir. MulticastDelegate / Delegate hibrit sınıfı olan kara kutuyla bu neredeyse imkansızdır, yanitek bir abone kullanmaya ve / veya işleyici zinciri kullanılırken / değiştirilirken çıkarılabilen bir senkronizasyon tutamağına sahip kendi MulticastDelegate türünü uygular . Bunu tavsiye ediyorum, çünkü alternatif, tüm işleyicilerinizde gereksizce / gereksiz derecede karmaşık olacak şekilde eşitleme / işlemsel bütünlüğü uygulamak olacaktır.

Lütfen buraya bir göz atın: http://www.danielfortunov.com/software/%24daniel_fortunovs_adventures_in_software_development/2009/04/23/net_event_invocation_thread_safety Bu doğru çözümdür ve diğer tüm geçici çözümler yerine her zaman kullanılmalıdır.

“Dahili çağırma listesinin her zaman en az bir üyeye sahip olmasını sağlamak için, bunu yapmadan isimsiz bir yöntemle başlatabilirsiniz. Hiçbir dış taraf anonim yönteme başvuru yapamayacağından, dış taraf hiçbir yöntemi kaldıramaz, bu nedenle temsilci hiçbir zaman boş kalmayacaktır ”- Programlama .NET Bileşenleri, 2. Baskı, Juval Löwy

public static event EventHandler<EventArgs> PreInitializedEvent = delegate { };  

public static void OnPreInitializedEvent(EventArgs e)  
{  
    // No check required - event will never be null because  
    // we have subscribed an empty anonymous delegate which  
    // can never be unsubscribed. (But causes some overhead.)  
    PreInitializedEvent(null, e);  
}  

Sorunun c # "olay" türüyle sınırlı olduğuna inanmıyorum. Bu kısıtlamayı kaldırarak, neden tekerleği biraz yeniden icat edip bu çizgiler boyunca bir şey yapmıyorsunuz?

Etkinlik dizisini güvenle kaldırın - en iyi yöntem

• Yükseltme dahilindeyken herhangi bir iplikten alt / abonelikten çıkma yeteneği (yarış durumu kaldırıldı)
• Sınıf düzeyinde + = ve - = için aşırı yük.
• Genel arayan tanımlı temsilci

Yararlı bir tartışma için teşekkürler. Son zamanlarda bu sorun üzerinde çalışıyordu ve biraz daha yavaş, ama atılan nesnelere çağrıları önlemek için izin veren aşağıdaki sınıfı yaptı.

Burada asıl nokta, olay gündeme gelse bile çağrı listesinin değiştirilebileceğidir.

/// <summary>
/// Thread safe event invoker
/// </summary>
public sealed class ThreadSafeEventInvoker
{
    /// <summary>
    /// Dictionary of delegates
    /// </summary>
    readonly ConcurrentDictionary<Delegate, DelegateHolder> delegates = new ConcurrentDictionary<Delegate, DelegateHolder>();

    /// <summary>
    /// List of delegates to be called, we need it because it is relatevely easy to implement a loop with list
    /// modification inside of it
    /// </summary>
    readonly LinkedList<DelegateHolder> delegatesList = new LinkedList<DelegateHolder>();

    /// <summary>
    /// locker for delegates list
    /// </summary>
    private readonly ReaderWriterLockSlim listLocker = new ReaderWriterLockSlim();

    /// <summary>
    /// Add delegate to list
    /// </summary>
    /// <param name="value"></param>
    public void Add(Delegate value)
    {
        var holder = new DelegateHolder(value);
        if (!delegates.TryAdd(value, holder)) return;

        listLocker.EnterWriteLock();
        delegatesList.AddLast(holder);
        listLocker.ExitWriteLock();
    }

    /// <summary>
    /// Remove delegate from list
    /// </summary>
    /// <param name="value"></param>
    public void Remove(Delegate value)
    {
        DelegateHolder holder;
        if (!delegates.TryRemove(value, out holder)) return;

        Monitor.Enter(holder);
        holder.IsDeleted = true;
        Monitor.Exit(holder);
    }

    /// <summary>
    /// Raise an event
    /// </summary>
    /// <param name="args"></param>
    public void Raise(params object[] args)
    {
        DelegateHolder holder = null;

        try
        {
            // get root element
            listLocker.EnterReadLock();
            var cursor = delegatesList.First;
            listLocker.ExitReadLock();

            while (cursor != null)
            {
                // get its value and a next node
                listLocker.EnterReadLock();
                holder = cursor.Value;
                var next = cursor.Next;
                listLocker.ExitReadLock();

                // lock holder and invoke if it is not removed
                Monitor.Enter(holder);
                if (!holder.IsDeleted)
                    holder.Action.DynamicInvoke(args);
                else if (!holder.IsDeletedFromList)
                {
                    listLocker.EnterWriteLock();
                    delegatesList.Remove(cursor);
                    holder.IsDeletedFromList = true;
                    listLocker.ExitWriteLock();
                }
                Monitor.Exit(holder);

                cursor = next;
            }
        }
        catch
        {
            // clean up
            if (listLocker.IsReadLockHeld)
                listLocker.ExitReadLock();
            if (listLocker.IsWriteLockHeld)
                listLocker.ExitWriteLock();
            if (holder != null && Monitor.IsEntered(holder))
                Monitor.Exit(holder);

            throw;
        }
    }

    /// <summary>
    /// helper class
    /// </summary>
    class DelegateHolder
    {
        /// <summary>
        /// delegate to call
        /// </summary>
        public Delegate Action { get; private set; }

        /// <summary>
        /// flag shows if this delegate removed from list of calls
        /// </summary>
        public bool IsDeleted { get; set; }

        /// <summary>
        /// flag shows if this instance was removed from all lists
        /// </summary>
        public bool IsDeletedFromList { get; set; }

        /// <summary>
        /// Constuctor
        /// </summary>
        /// <param name="d"></param>
        public DelegateHolder(Delegate d)
        {
            Action = d;
        }
    }
}

Ve kullanımı:

    private readonly ThreadSafeEventInvoker someEventWrapper = new ThreadSafeEventInvoker();
    public event Action SomeEvent
    {
        add { someEventWrapper.Add(value); }
        remove { someEventWrapper.Remove(value); }
    }

    public void RaiseSomeEvent()
    {
        someEventWrapper.Raise();
    }

Ölçek

Aşağıdaki şekilde test ettim. Bu gibi nesneleri oluşturur ve yok eden bir iş parçacığı var:

var objects = Enumerable.Range(0, 1000).Select(x => new Bar(foo)).ToList();
Thread.Sleep(10);
objects.ForEach(x => x.Dispose());

Bir Bar(dinleyici nesnesi) yapıcısında abone oldum SomeEvent(yukarıda gösterildiği gibi uygulanır) ve abonelikten çıkarım Dispose:

    public Bar(Foo foo)
    {
        this.foo = foo;
        foo.SomeEvent += Handler;
    }

    public void Handler()
    {
        if (disposed)
            Console.WriteLine("Handler is called after object was disposed!");
    }

    public void Dispose()
    {
        foo.SomeEvent -= Handler;
        disposed = true;
    }

Ayrıca bir döngüde olay yükselten iş parçacığı bir çift var.

Tüm bu eylemler aynı anda gerçekleştirilir: birçok dinleyici oluşturulur ve yok edilir ve olay aynı anda tetiklenir.

Bir yarış koşulu varsa, bir konsolda bir mesaj görmeliyim, ancak boş. Ancak clr olaylarını her zamanki gibi kullanırsam uyarı mesajlarıyla dolu görürüm. Yani, c # bir iş parçacığı güvenli olaylar uygulamak mümkün olduğu sonucuna varabiliriz.

Ne düşünüyorsun?