![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenРазмышлял как-то над юнит тестированием многопоточного кода - возможно ли оно, и как бы это так выкрутить.
Предположения:
1. Нам нужно про-юнит-тестить два треда, выполняющие разный или одинаковый код.
2. Специфические для мультитредовых программ ошибки возникают из-за race conditions (и синхронизации их результатов в разных видах).
Достаточно глупая идея:
1. Расставить в коде всех тредов вручную (вызовами специальных функций) или автоматически (анализом байт-кода) "контрольные точки", в которых возникают race conditions на чтение или запись. Пусть это будут в первом треде p1, p2, ... pn, и во втором - q1, q2, ...., qm.
2. Тупо прогнать тестируемые треды так, чтобы точки синхронизировались во всех возможных сочетаниях: а) (p1 с q1 и p2 с q2, ...) б) (p1 с q2 и p2 с q3, ...), ... в) (p1 с q1, p2 c никакой) и т.д. Ва) (p1 с q1 и p2 с q2, ...)
Всего будет конечное количество таких множеств пар, кажется, M!*N!. Много. Можно проредить, оставить только те множества пар, которые пересекаются по одной и той же переменной. Это уменьшит сложность задачи на порядки - теперь это будет сумма величин (Mi!)*(Ni!), где Mi и Ni - количество точек race conditions по i-й переменной. Это гораздо меньше, и автоматически это можно перебрать.
Покритикуйте идею, пожалуйста :)
P.S. Блин, как набрать формулу в HTML? :)
Предположения:
1. Нам нужно про-юнит-тестить два треда, выполняющие разный или одинаковый код.
2. Специфические для мультитредовых программ ошибки возникают из-за race conditions (и синхронизации их результатов в разных видах).
Достаточно глупая идея:
1. Расставить в коде всех тредов вручную (вызовами специальных функций) или автоматически (анализом байт-кода) "контрольные точки", в которых возникают race conditions на чтение или запись. Пусть это будут в первом треде p1, p2, ... pn, и во втором - q1, q2, ...., qm.
2. Тупо прогнать тестируемые треды так, чтобы точки синхронизировались во всех возможных сочетаниях: а) (p1 с q1 и p2 с q2, ...) б) (p1 с q2 и p2 с q3, ...), ... в) (p1 с q1, p2 c никакой) и т.д. Ва) (p1 с q1 и p2 с q2, ...)
Всего будет конечное количество таких множеств пар, кажется, M!*N!. Много. Можно проредить, оставить только те множества пар, которые пересекаются по одной и той же переменной. Это уменьшит сложность задачи на порядки - теперь это будет сумма величин (Mi!)*(Ni!), где Mi и Ni - количество точек race conditions по i-й переменной. Это гораздо меньше, и автоматически это можно перебрать.
Покритикуйте идею, пожалуйста :)
P.S. Блин, как набрать формулу в HTML? :)
Tags:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
30/9/05 07:41 (UTC)p.s.: формулу в HTML - никак. благодари Кнута - когда к нему приходили, чтобы попросить TeX для гипертекстового языка, он не дал. В результате взяли SGML и породили HTML :(
(no subject)
30/9/05 15:13 (UTC)Мне пообещали подкинуть ссылок на теорию вопроса - race conditions и т.п. Пока что вот что говорит наш эксперт:
На предлагаемую тобой тему есть много злобных научных работ. Попробую найти наиболее типичные.
Если не делать "общих данных", к которым кто угодно когда угодно подлезть может, то не понадобится их и защищать.
В твоём списке кто-то уже говорил (как бы не ты сам?), что все относящиеся к делу данные надо передавать по каналам. CSP = communicating sequential processes.
Канал - это типизированный контейнер. С syncronized операциями get и put.
В Limbo и Erlang есть каналы. В Аде тоже передача данных между тасками(тредами) организована похожим образом.
Правда, темы "тредо-плохих" языков типа Java он пока не затронул.
(no subject)
16/11/05 08:59 (UTC)Так-таки concurrency problems выражаются только в read-write и write-write conflicts.
Следовательно, обращения к таким данным и есть те самые "критические точки". Это можно реализовать даже анализом байткода... :)