Des threads vs re-participant

Récemment, j'ai posé une question, avec le titre de "Malloc est thread-safe?", et à l'intérieur que j'ai demandé, "Est malloc re-venu?"

J'étais sous l'impression que tous les concurrents sont thread-safe.

Cette hypothèse est fausse?

InformationsquelleAutor Alphaneo | 2009-05-13
  1. 40

    Ré-entrant fonctions ne s'appuient pas sur des variables globales qui sont exposées dans la bibliothèque C-têtes .. prendre strtok() vs strtok_r() par exemple dans C.

    Certaines fonctions ont besoin d'un endroit pour stocker un "travail en cours", ré-entrant fonctions vous permettent de spécifier ce pointeur dans le thread propre espace de stockage, non pas dans un mondial. Depuis ce stockage est exclusif à l'appel de la fonction, il peut être interrompu et re-entré (ré-entrant) et puisque dans la plupart des cas d'exclusion mutuelle au-delà de ce que la fonction met en œuvre n'est pas nécessaire pour faire ce travail, ils sont souvent considérés comme des thread-safe. Ce n'est pas, cependant, garanti par définition.

    errno, cependant, est un cas un peu différent sur les systèmes POSIX (et tend à être la pièce la plus singulière dans toute explication de la façon dont tout cela fonctionne) 🙂

    En bref, réentrant souvent signifie "thread-safe" (comme dans "utiliser la version réentrante de cette fonction si vous êtes à l'aide de threads"), mais "thread-safe" ne signifie pas toujours ré-entrant (ou l'inverse). Lorsque vous êtes à la recherche au fil de sécurité, simultanéité est ce que vous devez penser. Si vous avez à fournir un moyen de verrouillage et d'exclusion mutuelle pour utiliser une fonction, la fonction n'est pas intrinsèquement thread-safe.

    Mais, pas toutes les fonctions doivent être examinées pour soit. malloc() n'a pas besoin d'être réentrant, il ne dépend pas de quoi que ce soit hors de la portée du point d'entrée pour n'importe quel thread donné (et qui est lui-même thread-safe).

    Les fonctions qui retournent des allouée statiquement les valeurs sont pas thread-safe, sans l'utilisation d'un mutex, futex, ou d'autres atomique mécanisme de verrouillage. Pourtant, ils n'ont pas besoin d'être réentrant si ils ne vont pas être interrompu.

    c'est à dire:

    static char *foo(unsigned int flags)
{
  static char ret[2] = { 0 };

  if (flags & FOO_BAR)
    ret[0] = 'c';
  else if (flags & BAR_FOO)
    ret[0] = 'd';
  else
    ret[0] = 'e';

  ret[1] = 'A';

  return ret;
}

    Donc, comme vous pouvez le voir, le fait d'avoir plusieurs threads utilisent que sans une sorte de verrouillage serait une catastrophe .. mais il n'a pas vocation à être ré-entrant. Vous découvrirez que lorsque la mémoire allouée dynamiquement est tabou sur certaines plate-forme embarquée.

    Purement fonctionnelle de la programmation, réentrant souvent n'est pas implique thread-safe, cela dépend du comportement de défini ou d'une fonction anonyme transmise à la fonction de point d'entrée, la récursivité, etc.

    Une meilleure façon de mettre "thread-safe" est sécurité pour l'accès simultané , qui illustre le mieux le besoin.

    • Réentrant n'implique pas thread-safe. Les fonctions pures implique thread-safety.
    • Grande réponse de Tim. Juste pour préciser, ma compréhension de votre "souvent", c'est que "thread-safe" ne signifie pas réentrant, mais aussi réentrant ne signifie pas thread-safe. Seriez-vous capable de trouver un exemple de fonction réentrante qui est pas "thread-safe"?
    • Tim Post "En bref, réentrant signifie souvent" thread-safe " (comme dans "utiliser la version réentrante de cette fonction si vous êtes à l'aide de threads"), mais "thread-safe" ne signifie pas toujours ré-entrant." qt dit en face: "c'est pourquoi, un thread fonction de sécurité est toujours réentrant, mais une fonction réentrante n'est pas toujours thread-safe".
    • et wikipedia dit encore autre chose: "Cette définition de la réentrance diffère de celle du filet de sécurité dans les environnements multi-threadés. Réentrante sous-routine peut atteindre fil de sécurité,[1], mais le fait réentrant seule peut ne pas être suffisante pour être thread-safe dans toutes les situations. À l'inverse, thread-safe code ne doit pas nécessairement être réentrant (...)"
    • Fonctions synchronisées par le biais de variables mais pas sur toute les barrières de la mémoire pour une utilisation avec signal/gestionnaires d'interruption sont généralement re-venu, mais thread-safe.
    InformationsquelleAutor Tim Post
  2. 66

    TL;DR: UNE fonction peut être réentrant, thread-safe, les deux ou aucun des deux.

    Les articles de Wikipédia pour fil-sécurité et la réentrance sont bien la peine de lire. Voici quelques citations:

    Une fonction est thread-safe si:

    il ne manipule des structures de données partagées
    d'une manière qui garantit la sécurité de l'exécution par plusieurs
    threads en même temps.

    Une fonction est réentrant si:

    il peut être interrompu à tout moment au cours de son exécution
    et puis en toute sécurité appelle à nouveau ("ré-entrée") avant son
    précédent invocations exécution complète.

    Comme des exemples de réentrance, la Wikipédia donne l'exemple d'une fonction conçue pour être appelée par le système interrompt: supposons qu'il est déjà en cours d'exécution lorsqu'un autre interruption se produit. Mais ne pensez pas que vous êtes en sécurité simplement parce que vous n'avez pas de code avec les interruptions système: vous pouvez re-ouverture de problèmes dans un seul thread programme si vous utilisez des rappels ou des fonctions récursives.

    La clé pour éviter toute confusion, c'est que réentrant se réfère à
    un seul thread en cours d'exécution. C'est un concept à partir du moment où
    aucun des systèmes d'exploitation multitâches existé.

    Exemples

    (Légèrement modifié à partir de l'article de Wikipedia)

    Exemple 1: pas thread-safe, non réentrant

    /* As this function uses a non-const global variable without
   any precaution, it is neither reentrant nor thread-safe. */

int t;

void swap(int *x, int *y)
{
    t = *x;
    *x = *y;
    *y = t;
}

    Exemple 2: thread-safe, non réentrant

    /* We use a thread local variable: the function is now
   thread-safe but still not reentrant (within the
   same thread). */

__thread int t;

void swap(int *x, int *y)
{
    t = *x;
    *x = *y;
    *y = t;
}

    Exemple 3: n'est pas thread-safe, réentrant

    /* We save the global state in a local variable and we restore
   it at the end of the function.  The function is now reentrant
   but it is not thread safe. */

int t;

void swap(int *x, int *y)
{
    int s;
    s = t;
    t = *x;
    *x = *y;
    *y = t;
    t = s;
}

    Exemple 4: thread-safe, réentrant

    /* We use a local variable: the function is now
   thread-safe and reentrant, we have ascended to
   higher plane of existence.  */

void swap(int *x, int *y)
{
    int t;
    t = *x;
    *x = *y;
    *y = t;
}
    • Je sais que je ne suis pas censé commentaire juste pour dire merci, mais c'est l'une des meilleures illustrations de la pose sur les différences entre le participant et le fil les fonctions de sécurité. En particulier, vous avez utilisé de manière très concise, claire, et a choisi un excellent exemple de la fonction de distinguer entre les 4 catégories. Donc, Merci!
    • Une fonction est à la fois réentrant et thread-safe si elle n'utilise pas l'échelle mondiale /static var. Thread - safe": lorsque le nombre de threads exécute votre fonction dans le même temps, est-il la course?? Si vous utiliser le var, l'utilisation de lock pour le protéger. donc, il n'est pas thread-safe. réentrant: si un signal se produit au cours de votre exécution de la fonction, et appelez votre fonction dans le signal de nouveau, est-il sûr??? dans de tels cas, il n'y a pas plusieurs threads. vous ne devez pas utiliser de l'électricité statique/global var pour faire réentrant...
    • Il me semble thay exemple 3 n'est pas réentrant: si un gestionnaire de signal, interrompant après t = *x, les appels swap(), puis t sera remplacée, conduisant à des résultats inattendus.
    • comment est l'exemple 3 réentrant?
    • prenons l'exemple d'un appel à swap(5, 6) d'être interrompu par une swap(1, 2). Après t=*x, s=t_original et t=5. Maintenant, après l'interruption, s=5 et t=1. Cependant, avant la seconde swap retourne il sera de restaurer contexte, ce qui rend t=s=5. Maintenant, nous allons revenir à la première swap avec t=5 and s=t_original et continuer après t=*x. Donc, la fonction ne semble pas être ré-entrant. Rappelez-vous que chaque appel obtient sa propre copie de s alloué sur la pile.
    • Votre exemple est difficile à comprendre, probablement à cause de beaucoup de mots et de mon incapacité à imaginer, à cette heure, mais vous avez dit quelque chose le long des lignes avant le deuxième swap retourne il sera de restaurer contexte, sur base de la dernière cession, t=s, à droite? Mais le changement de contexte peut arriver n'importe quand, alors, si c'est renvoyée avant que, maintenant t est modifié, *y obtient une valeur différente. Règle de base de la réentrance est, de ne pas muck autour avec global sans mutex protection.
    • L'hypothèse est que si la fonction est interrompue (en tout point), c'est seulement pour être appelé de nouveau, et nous attendons jusqu'à ce qu'elle se termine avant de continuer à l'appel original. Si autre chose se passe, alors, c'est essentiellement le multithreading, et cette fonction est pas thread-safe. Supposons que la fonction ne ABCD, nous n'acceptons que des choses comme AB_ABCD_CD, ou A_ABCD_BCD, ou même UN__AB_ABCD_CD__BCD. Comme vous pouvez le vérifier, exemple 3 marcherait bien en vertu de ces hypothèses, il est réentrant. Espérons que cette aide.
    • mutex serait effectivement le faire non réentrant. La première invocation de serrures de mutex. En arrive à la seconde invocation de blocage.
    • que voulez-vous dire changement de contexte peut arriver à tout moment? CPU devrait garantir observables de l'ordre.
    • Je vous recommande de base multi-threading tutoriels, et quelques lectures sur la façon dont un blocage fonctionne réellement.

    InformationsquelleAutor MiniQuark
  3. 55

    Cela dépend de la définition. Par exemple Qt utilise suivantes:

    • Un thread-safe* fonction peut être appelée simultanément à partir de plusieurs threads, même lorsque les invocations utilisation de données partagée, parce que toutes les références à des données partagées sont sérialisés.

    • Un réentrant fonction peut également être appelée simultanément à partir de plusieurs threads, mais seulement si chaque invocation utilise ses propres données.

    Par conséquent, une thread-safe fonction est toujours réentrant, mais un réentrant fonction n'est pas toujours thread-safe.

    Par extension, une classe est dite réentrant si ses fonctions de membre peut être appelé en toute sécurité à partir de plusieurs threads, aussi longtemps que chaque thread utilise une autre instance de la classe. La classe est thread-safe si ses fonctions de membre peut être appelé en toute sécurité à partir de plusieurs threads, même si tous les threads utilisent la même instance de la classe.

    mais ils ont aussi attention:

    Remarque: la Terminologie dans le multithreading de domaine n'est pas entièrement normalisé. POSIX utilise des définitions de réentrant et thread-safe qui sont un peu différentes pour son C Api. Lors de l'utilisation d'autres orientée objet bibliothèques de classe C++ avec Qt, assurez-vous que les définitions sont compris.

    • Cette définition de réentrant est trop forte.
    • Downvote. Un thread fonction de sécurité n'est PAS toujours réentrant.
    • Une fonction est à la fois réentrant et thread-safe si elle n'utilise pas l'échelle mondiale /static var. Thread - safe": lorsque le nombre de threads exécute votre fonction dans le même temps, est-il la course?? Si vous utiliser le var, l'utilisation de lock pour le protéger. donc, il n'est pas thread-safe. réentrant: si un signal se produit au cours de votre exécution de la fonction, et appelez votre fonction dans le signal de nouveau, est-il sûr??? dans de tels cas, il n'y a pas plusieurs threads. Le mieux est de ne pas utiliser toute la statique/global var pour faire réentrant, ou comme dans l'exemple 3.
    InformationsquelleAutor Georg Schölly