8 thoughts on “Dobre i złe praktyki w C# – część II”

1. A czemu te artykuły są w kategorii “ASP-NET” na MSDN? 🙂

2. Dzieki za uwage. Blad przy publikacji. Cykl bedzie ogolnie o c# a nie o ASP.NET.

3. Witam
   Miałem ostatnio dość ciekawą sytuację związaną z wątkami. Mianowicie tworzyłem nowy wątek za pomocą delegata w którym odbywał się pooling pewnych urządzeń aż do wystąpienia warunku zakończenia poolingu. Przed wystartowaniem nowego wątku tworzyłem w wątku głównym pewien obiekt-obiekt1 do któego były podpięte zdarzenia. I teraz w wątku wykonującym pooling te zdarzenia były wywoływane, knif polegał na tym że jeśli nie odpiąłem zdarzeń przed zakończeniem poolingu to przy powtórzeniu wszystkich kroków od nowa wątek w tle pamiętał stany poprzedniego obiektu-obiekt1 natomiast wszystkie inne zmienne które nie miały podpiętych zdarzeń posiadały wartości domyślne czyli ok. Czytając twój artykuł doszedłem do wniosu, że ma to związek z pulą wątków. Tylko nie potrafię sobie jeszcze wytłumaczyć dlaczego zdarzenia tak wpływają na wątek. Może masz jakiś pomysł?

4. Witam
   Mozesz napisac jakis przykladowy kod? Zdarzenia zwykle trzeba odpinac bo moze to spowodowac memory leak.
   Watki z puli to watki ktore nie sa usuwane z pamieci a po prostu po zakonczeniu pracy z powrotem sa wrzucane do puli.
   Wrzuc jakis przykladowy kod to wtedy moze bedziemy w stanie doradzic cos.

5. Na MSDN jest podobny artykuł (http://msdn.microsoft.com/en-us/library/ff650316.aspx). “Static initialization is suitable for most situations. When your application […] work in a multithreaded environment, you need a different solution. Cases do exist, however, in which you cannot rely on the common language runtime to ensure thread safety, as in the Static Initialization example. In such cases, you must use specific language capabilities to ensure that only one instance of the object is created in the presence of multiple threads. One of the more common solutions is to use the Double-Check Locking [Lea99] idiom to keep separate threads from creating new instances of the singleton at the same time.” Tamta wersja Singleton z polem “static” nie jest określona jako multi-threaded. Wielowątkowa jest tylko wersja z double-checked-locking. W Twoim artykule wersja z polem “static” bez locków, jest określona jako multi-threaded w lepszym wydaniu. Kto ma rację?

6. Hey,
   Nie rozumiem. Ktora klasa wedlug Ciebie i MSDN nie jest thread-safe?

7. Może coś źle zrozumiałem, ale chodzi o ten Singleton:

   public sealed class Singleton
   {
   private static readonly Singleton instance = new Singleton();

   private Singleton(){}

   public static Singleton Instance
   {
   get { return instance; }
   }
   }

8. Hmm nie bardzo wiem dlaczego taka implementacja mialaby nie byc thread-safe. W kazdym razie musze poczytac o tym moze faktycznie istnieja jakies race condition.