C++ nouvel opérateur sécurité des threads sous linux et gcc 4

Je vais bientôt commencer à travailler sur une version parallèle d'un raffinement de maillage algorithme utilisant la mémoire partagée.

Professeur à l'université de souligner qu'il faut être très prudent au sujet de la sécurité des threads parce que ni le compilateur ni la stl est thread courant.

J'ai cherché pour cette question et la réponse dépendait du compilateur (certains essayent d'être un peu thread courant) et la plattform (si les appels système utilisé par le compilateur sont thread-safe ou pas).

Donc, dans linux, gcc 4 compilateur produit thread-safe code pour le nouvel opérateur?

Si non, quelle est la meilleure façon de surmonter ce problème? Peut-être verrouiller chaque appel à l'opérateur new?

OriginalL'auteur Gaston | 2009-04-28

  1. 16

    Vous aurez à examiner de très difficile de trouver une plate-forme qui prend en charge les threads, mais n'ont pas thread-safe new. En fait, le fil de sécurité de new (et malloc) est l'une des raisons pour lesquelles il est si lent.

    Si vous voulez un thread-safe TSL sur l'autre main, vous pouvez envisager de Intel TBB qui a thread courant des conteneurs (bien que toutes les opérations ne sont pas thread-safe).

    OriginalL'auteur Max Lybbert

  2. 8

    Généralement le new opérateur est thread-safe - toutefois fil de garanties de sécurité pour les appels au sein de la STL et de la bibliothèque standard sont régies par la norme - ce qui ne signifie pas qu'ils sont thread ignorent - ils ont tendance à avoir très bien défini les garanties de la sécurité des threads pour certaines opérations. Par exemple itérer sur une liste en lecture seule de la mode est thread-safe pour plusieurs lecteurs, tout en évoluant dans une liste et de faire les mises à jour ne l'est pas. Vous devez lire la documentation et de voir quelles sont les différentes garanties sont, même si elles ne sont pas lourdes et ils ont tendance à faire sens.

    Et dans ce cas, le nouvel opérateur n'est pas thread-safe? Dois-je m'inquiéter à ce sujet ou simplement l'utiliser?
    C'est à votre compilateur fournisseur ou de mise en œuvre - par exemple en visual C++, vous aurez à choisir entre un multithread de la bibliothèque standard ou un seul thread de la bibliothèque, mais pas trop le choix de ces jours, comme à peu près tout de l'intérêt nécessite l'utilisation de l'multithread de la bibliothèque.

    OriginalL'auteur 1800 INFORMATION

  3. 2

    Alors que je parle de concepts que je n'ai pas utilisé, je pense que je devrais mentionner que si vous êtes en utilisant la mémoire partagée, alors il est probable que vous voulez vous assurer que vous utilisez seulement POD types, et d'utiliser le placement de nouveaux.

    Deuxièmement, si vous êtes en utilisant la mémoire partagée, comme il est communément entendu que sur les systèmes linux, vous pouvez être en utilisant plusieurs processus - pas de fils, d'allouer de la mémoire et de "faire les choses" - utilisation de la mémoire partagée comme une couche de communication. Si c'est le cas, alors le fil de sécurité de votre application et les bibliothèques ne sont pas importants - ce qui est important, cependant, est le fil de sécurité de quoi que ce soit à l'aide de l'allocation de mémoire partagée! C'est une situation différente que l'exécution d'un processus avec de nombreux fils, auquel cas poser des questions sur le thread de la sécurité de l'opérateur new EST une préoccupation légitime, et pourraient être traitées par le placement de nouveau, si elle n'est pas, ou en définissant votre propre allocateurs.

    OriginalL'auteur Arafangion

  4. 1

    Bien, ce n'est pas une réponse définitive à ma question, c'est juste que j'ai découvert que Google a mis en œuvre un haute performance multi-thread malloc.

    Donc, si vous êtes dans le doute de savoir si votre application est thread-safe, vous devriez peut-être utiliser le Google Outils De Performance.

    OriginalL'auteur Gaston