Que signifie "intrinsèquement thread-safe"?

Question

Je suis tombé sur cette ligne "certaines fonctions sont intrinsèquement thread-safe, par exemple memcpy() "

Wikipedia définit "thread-safe" comme:

Un morceau de code est thread-safe s'il ne manipule les structures de données partagées que de manière à garantir une exécution sécurisée par plusieurs threads en même temps.

D'ACCORD. Mais que signifie intrinsèquement ? Est-ce lié à l'héritage?

Answer 1

Ce n'est pas lié à l'héritage . C'est une expression informelle et signifie plus comme
"certaines fonctions sont thread-safe par nature". Par exemple une fonction qui ne
touchez toutes les valeurs partagées / l'état est thread-safe de toute façon, par exemple "est intrinsèquement thread-safe"

Answer 2

Dans ce contexte, je l'interpréter comme "sans avoir été conçu pour l'atteindre, c'est toujours le "thread-safe".

Il n'y a pas de lien direct avec le concept d'héritage, bien que les mots sont liés. Ce n'est pas un exemple de succession à la programmation orientée objet sens, bien sûr. Ce n'est qu'une fonction, qu'à partir de son cœur de la nature devient la propriété d'être thread-safe.

Bien sûr, il n'y a rien de magique à propos de memcpy() étant intrinsèquement thread-safe, soit. Toute fonction sans état interne ou "partagé" effets secondaires sera donc, c'est pourquoi la programmation fonctionnelle, où toutes les fonctions sont censés être "pur" et l'absence d'effets secondaires, se prête si bien à la programmation parallèle.

Dans la pratique, il est difficile sur les ordinateurs pour obtenir un vrai travail fait sans effets secondaires, en particulier l'e/S est très bien défini par ses effets secondaires. Donc, même pur les langages fonctionnels ont souvent de la non-fonctionnelle coins.

Mise à jour: bien sûr, memcpy() n'est pas exempt d'effets secondaires, il est de base le but est de manipuler la mémoire qui, si elle est partagée entre les threads, certes ce n'est pas à l'abri. L'hypothèse est qu'aussi longtemps que les zones de destination sont distincts, il n'a pas d'importance si un ou plusieurs threads s'exécutent memcpy() en parallèle.

Cela contraste avec, par exemple, printf(), ce qui génère des caractères sur un seul (le processus) flux de sortie. Il doit être explicitement mis en œuvre (comme requis par la norme POSIX) être thread-safe, alors qu' memcpy() ne le sont pas.

Answer 3

Par nature un "thread-safe" de la fonction, et est en sécurité sans avoir à prendre de conception spécifique, les décisions concernant le filetage, il est thread-safe, tout simplement en raison de la tâche qu'il effectue plutôt que d'être repensé à la force de sécurité des threads. Dis-je écrire la fonction très simple:

int cube(int x)
{
    return x*x*x;
}

Il est intrinsèquement thread-safe, comme il n'a aucun moyen de lecture ou écriture à la mémoire partagée. Cependant je pourrais aussi faire une fonction qui n'est pas thread-safe, mais en faire thread-safe par le biais de la conception et de la synchronisation. Dire que j'ai cette fonction similaire à avant:

void cubeshare()
{
    static int x;
    x = x * x * x;
    printf("%l", x);
}

Ce n'est pas thread-safe, il est tout à fait possible, il pourrait avoir la valeur de x change entre chaque utilisation (eh bien, ce est en fait peu probable dans la réalité que x serait mise en cache, mais disons que nous n'en faisons pas toute optimisation).

Nous avons cependant pu faire de ce "thread-safe" comme ceci (c'est le pseudo-code, un vrai mutex est plus compliqué):

void cubesharesafe(mutex foo)
{
    static int x;
    lockmutex(foo);
    x = x * x * x;
    printf("%l", x);
    unlockmutex(foo);
}

Toutefois, ce n'est pas, en soi, thread-safe, nous obligent à être par une refonte. Des exemples concrets seront souvent beaucoup plus compliqué que cela, mais j'espère que cela donne une idée pris le plus simple possible. Si vous avez des questions, s'il vous plaît commentaire ci-dessous.

Answer 4

Dans le cas de memcpy , un seul thread est capable de fournir des écritures d'une source spécifique vers une destination spécifique. : thread-safe par conception initiale donc.

Signifie intrinsèquement : sans avoir besoin de "régler" la fonction de base pour atteindre l'objectif, dans ce cas: la sécurité des threads.

Si plusieurs threads pouvaient interférer dans le même "canal" en même temps, vous vous retrouveriez avec un problème de sécurité des threads lié aux mandrins de données partagés.

Answer 5

inhérent signifie Exister dans quelque chose en tant que permanent. cela n'a rien à voir avec l'héritage .. par défaut, ou déjà certaines méthodes sont thread-safe ... afin de protéger ou d'éviter les problèmes multitâches .. vector, table de hachage .. sont quelques exemples de classes qui sont intrinsèquement thread-safe. .not..confusant..il y a quelques fonctions..qui est thread-safe par défaut ..