[mOved] [F] Votre bureau » Windows 8 - Page 15

Brunni (./419) :
... en faisant 2 accès successifs d'un même thread dans mon appli Métro \o/

        #region Singleton boilerplate code (v2)
        private static readonly Lazy<ClientLibrary> instance = new Lazy<ClientLibrary>(() => new ClientLibrary());

        public static ClientLibrary Instance
        {
            get { return instance.Value; }
        }

        private ClientLibrary() { }
        #endregion

        private static readonly ClientLibrary instance = new ClientLibrary();

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

        static ClientLibrary() { }

        private ClientLibrary() { }

GoldenCrystal (./426) :
Ça devrait économiser quelques octets de mémoire, et peut-être quelques cycles à chaque accès. (J'en suis presque certain, j'ai juste la flemme de faire les tests )

Brunni (./419) :
J'ai réussi à faire un singleton où j'obtiens deux instances différentes en faisant 2 accès successifs d'un même thread dans mon appli Métro \o/

        public static TrucMuche Instance
        {
            get
            {
                if (sharedInstance == null)
                    sharedInstance = new TrucMuche();
                return sharedInstance;
            }
        }

Dieu sait la merde qui s'est passé derrière

  private static QAtomicPointer<TrucMuche> sharedInstance;
  private static QMutex sharedInstanceMutex;
  public static TrucMuche *getInstance() {
    // fast lock-free path for the common case, using atomicity
    if (sharedInstance != 0)
      return sharedInstance;
    {
      QMutexLocker lock(&sharedInstanceMutex);
      if (sharedInstance != 0)
        return sharedInstance;
      TrucMuche *newInstance = new TrucMuche();
      sharedInstance = newInstance;
      return newInstance;
    }
  }

Zeph (./427) :
pourquoi le constructeur statique vide ?

Folco (./428) :

GoldenCrystal (./426) :
Ça devrait économiser quelques octets de mémoire, et peut-être quelques cycles à chaque accès. (J'en suis presque certain, j'ai juste la flemme de faire les tests )

Bon écoute Golden, si vraiment tu veux progresser en programmation, arrête de compter les cycles et les octets pour les langages de haut niveau, tu m'as compris ?

GoldenCrystal (./431) :
Kevin > Ne vaut-il pas mieux déplacer le code d'initialisation du singleton (le else dans ton code) dans une méthode séparée afin que la méthode getInstance() soit inlinée proprement ailleurs dans le code ?

GoldenCrystal (./431) :
Comme tu t'en doutes, l'initialisation des membres statiques se fait en réalité dans le constructeur statique, de même que l'initialisation des membres d'instance se fait dans le constructeur d'instance.

GoldenCrystal (./426) :
Pourquoi pas juste ça ?

        private static readonly ClientLibrary instance = new ClientLibrary();

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

        static ClientLibrary() { }

        private ClientLibrary() { }

Ça devrait économiser quelques octets de mémoire, et peut-être quelques cycles à chaque accès. (J'en suis presque certain, j'ai juste la flemme de faire les tests )

Zeph > J'aurai quand même été fort surpris que ce soit un bug du runtime .NET que personne n'ait jamais détecté… Mais j'avoue que tu m'as fait douter à un moment

Zeph (./434) :
Sinon dans ton article je ne vois pas une variante pourtant assez simple si on veut faire le double lock "à la main" :

Zeph (./434) :

GoldenCrystal (./431) :
Comme tu t'en doutes, l'initialisation des membres statiques se fait en réalité dans le constructeur statique, de même que l'initialisation des membres d'instance se fait dans le constructeur d'instance.

Heu non, avant ? Dans les deux cas (statique ou instance), les membres sont initialisés puis le constructeur (éventuellement vide) est appelé : http://www.csharp411.com/c-object-initialization/
Ça se constate assez facilement en regardant le MSIL généré, ou en mettant des breakpoints dans un constructeur et en constatant que tous les champs sont initialisés avant d'entrer à l'intérieur.

Je ne pense pas que définir ou non un constructeur vide (statique ou instance) change quoi que ce soit pour le coup.

Sinon dans ton article je ne vois pas une variante pourtant assez simple si on veut faire le double lock "à la main" :
if (instance == null) { lock (sync) { if (instance == null) Interlocked.Exchange (ref instance, new Singleton ()); } }
(la même avec le MemoryBarrier kivabien à la place de l'interlock exchange fonctionne également)

GoldenCrystal (./438) :
Heu…
J'ai vraiment du mal à te suivre là… Par quelle magie crois-tu que les champs (particulièrement les readonly ) sont initialisées s'ils ne sont pas placés dans le constructeur ?

1 - C'est pas parce que tu déclares pas un constructeur en C# qu'il n'y a pas de constructeur. / L'initialisation des champs se fait *dans* le vrai constructeur.

2 - Si tu déclares explicitement un constructeur statique, ça change la façon dont le vrai constructeur statique sera apellé/utilisé.

Heu… Mais quel est l'intérêt de Interlocked.Exchange ici ?
Le lock fait toutes les barrières mémoire nécessaires au double-checked locking, c'est d'ailleurs l'exemple numéro 3 dans le lien que j'ai posté !

GoldenCrystal (./438) :
Heu… Mais quel est l'intérêt de Interlocked.Exchange ici ?
Le lock fait toutes les barrières mémoire nécessaires au double-checked locking, c'est d'ailleurs l'exemple numéro 3 dans le lien que j'ai posté !

Zeph (./439) :

GoldenCrystal (./438) :
Heu…
J'ai vraiment du mal à te suivre là… Par quelle magie crois-tu que les champs (particulièrement les readonly ) sont initialisées s'ils ne sont pas placés dans le constructeur ?

Peut-être qu'on parle de deux choses différentes, moi de ce qu'on appelle "constructeur" dans n'importe quel langage objet, donc ici le constructeur écrit en C# (et ce n'est *pas* lui qui s'occupe des initialisations des attributs), et le code de construction généré qui forcément doit s'occuper de tout le boulot, dans l'ordre (i.e. attributs puis constructeur).

Heu… Mais quel est l'intérêt de Interlocked.Exchange ici ?
Le lock fait toutes les barrières mémoire nécessaires au double-checked locking, c'est d'ailleurs l'exemple numéro 3 dans le lien que j'ai posté !

Il y a vraiment la garantie que même sans memory barrier ça fonctionne, quel que soit le processeur et la version de .NET ? Il me semblait avoir entendu que non, mais je n'ai pas de lien sous la main.

La partie qui nous intéresse :
We’ve done targeted work to strengthen the memory model on ARM—specifically, we’ve inserted memory barriers at key points when writing to the managed heap to guarantee type safety—but we’ve made sure to only do this with a minimal impact on performance. The team went through multiple design reviews with experts to make sure that the techniques applied in the ARM CLR were correct. Moreover, performance benchmarks show that .NET code execution performance scales the same as native C++ code when compared across x86, x64 and ARM.
If your code relies on lock-free algorithms that depend on the implementation of the x86 CLR (rather than the ECMA CLR specification), you’ll want to add the volatile keyword to relevant variables as appropriate. Once you’ve marked shared state as volatile, the CLR will take care of everything for you. If you’re like most developers, you’re ready to run on ARM because you’ve already used locks to protect your shared data, properly marked volatile variables and tested your app on ARM.

[mOved] - Votre bureau » Windows 8

8.1.1 Guaranteed Atomic Operations
The Intel486 processor (and newer processors since) guarantees that the following basic memory operations will always be carried out atomically:
• Reading or writing a byte
• Reading or writing a word aligned on a 16-bit boundary
• Reading or writing a doubleword aligned on a 32-bit boundary
The Pentium processor (and newer processors since) guarantees that the following additional memory operations will always be carried out atomically:
• Reading or writing a quadword aligned on a 64-bit boundary
• 16-bit accesses to uncached memory locations that fit within a 32-bit data bus
The P6 family processors (and newer processors since) guarantee that the following additional memory operation will always be carried out atomically:
• Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line
Accesses to cacheable memory that are split across cache lines and page boundaries are not guaranteed to be atomic by the Intel Core 2 Duo, Intel® AtomTM, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors. The Intel Core 2 Duo, Intel Atom, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, and P6 family processors provide bus control signals that permit external memory subsystems to make split accesses atomic; however, nonaligned data accesses will seriously impact the performance of the processor and should be avoided. An x87 instruction or an SSE instructions that accesses data larger than a quadword may be implemented using multiple memory accesses. If such an instruction stores to memory, some of the accesses may complete (writing to memory) while another causes the operation to fault for architectural reasons (e.g. due an page-table entry that is marked “not present”). In this case, the effects of the completed accesses may be visible to software even though the overall instruction caused a fault. If TLB invalidation has been delayed (see Section 4.10.4.4), such page faults may occur even if all accesses are to the same page.