Threadsafe проти повторного вступу

Question 1

Нещодавно я задав запитання із заголовком "Чи безпечна нитка malloc?" , і всередині цього я запитав: "Malloc є повторним учасником?"

У мене склалося враження, що всі учасники, які повторно вступають, захищені від потоків.

Чи є це припущення помилковим?

Question 2

Функції повторного вступу не покладаються на глобальні змінні, які виставляються в заголовках бібліотеки C. .. візьмемо strtok () проти strtok_r (), наприклад, у C.

Деякі функції потребують місця для зберігання "незавершеного виробництва", функції повторного входу дозволяють вказати цей покажчик у власному сховищі потоку, а не в глобальному. Оскільки це сховище призначене виключно для функції, що викликає, його можна перервати та повторно ввести (повторно ввійти), і оскільки в більшості випадків взаємне виключення, що перевищує те, що реалізує функція, не потрібне для роботи, їх часто вважають нитка безпечна . Однак це не гарантується визначенням.

errno, однак, дещо інший випадок у системах POSIX (і, як правило, є дивним у будь-якому поясненні того, як все це працює) :)

Коротше кажучи, реентерант часто означає безпечний для потоку (як у "використовуйте версію цієї функції, що реагує, якщо ви використовуєте потоки"), але безпечний для потоку не завжди означає повторний вхід (або зворотний). Коли ви дивитесь на безпеку потоків, паралельність - це те, про що вам слід подумати. Якщо вам потрібно надати засіб блокування та взаємного виключення для використання функції, тоді функція за своєю суттю не є безпечною для потоків.

Але не всі функції потрібно перевіряти на будь-яку з них. malloc()не потребує повторного входу, це не залежить ні від чого, що виходить за рамки точки входу для будь-якого потоку (і саме є потокобезпечним).

Функціями, які повертають статично розподілені значення, є не безпечними для потоку без використання mutex, futex або іншого атомного механізму блокування. Тим не менше, їм не потрібно повертатися, якщо їх не збираються переривати.

тобто:

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;
}

Отже, як ви можете бачити, використання декількох потоків, що без якогось блокування буде катастрофою .. але це не має на меті бути повторним учасником. Ви натрапите на це, коли динамічно розподілена пам’ять є табу на якійсь вбудованій платформі.

У чисто функціональному програмуванні реентант часто цього не робить означає безпеку потоку, це залежатиме від поведінки визначених або анонімних функцій, переданих точці входу функції, рекурсії тощо.

Кращий спосіб забезпечити безпеку потокового зв'язку для одночасного доступу , що краще ілюструє потребу.

Question 3

TL; DR: функція може бути перенаправлена, захищена від потоків, як одна, так і інша.

Статті Вікіпедії про безпеку потоків та повернення варто прочитати. Ось кілька цитат:

Функція захищена від потоку, якщо:

він лише маніпулює спільними структурами даних таким чином, щоб гарантувати безпечне виконання кількома потоками одночасно.

Функція повертається, якщо:

його можна перервати в будь-який момент під час його виконання, а потім безпечно викликати знову ("повторно ввести") до завершення попереднього виклику.

Як приклади можливого повторного входу, Вікіпедія подає приклад функції, призначеної для виклику системними перериваннями: припустимо, вона вже працює, коли трапляється чергове переривання. Але не думайте, що ви в безпеці лише тому, що не кодуєте з системними перериваннями: у вас можуть виникнути проблеми з повторним входом в однопотоковій програмі, якщо ви використовуєте зворотні виклики або рекурсивні функції.

Ключовим для уникнення плутанини є те, що реентерант стосується лише одного потоку, що виконується. Це концепція того часу, коли не існувало багатозадачності операційних систем.

Приклади

(Трохи змінено зі статей Вікіпедії)

Приклад 1: не захищений від потоків, не повертається

/* 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;
}

Приклад 2: безпечний для потоку, не повертається

/* 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;
}

Приклад 3: не захищений від потоків, повертається

/* 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;
}

Приклад 4: ниткобезпечний, реентерабельний

/* 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;
}

Question 4

Це залежить від визначення. Наприклад, Qt використовує наступне:

Потокобезпечну * функцію можна одночасно викликати з декількох потоків, навіть коли для викликів використовуються спільні дані, оскільки всі посилання на спільні дані серіалізовані.

Поворотна функція також може викликатися одночасно з декількох потоків, але тільки тоді , коли кожен виклик використовує свої власні дані.

Отже, потокобезпечна функція завжди є ретрансляційною, але функція реентрантної не завжди є поточно безпечною.

Як розширення, клас називається реентрантним, якщо його функції-члени можуть бути безпечно викликані з декількох потоків, якщо кожен потік використовує інший екземпляр класу. Клас є безпечним для потоків, якщо його функції-члени можуть бути безпечно викликані з декількох потоків, навіть якщо всі потоки використовують один і той самий екземпляр класу.

але вони також застерігають:

Примітка. Термінологія в багатопотоковому домені не є повністю стандартизованою. POSIX використовує визначення реентерабельного та потокобезпечного, які дещо відрізняються для своїх API C. Використовуючи інші об'єктно-орієнтовані бібліотеки класів C ++ з Qt, переконайтеся, що визначення зрозумілі.