- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
Дали тестовое задание.
Написать хеш таблицу с открытой адресацией. Главное качество, а не скорость, сказали.
Реализовал на C++.
Самая тягомотина - это тестирование многопоточности.
Есть операции:
find, equalRange, operator [] - тот же equalRange, но возвращает все найденные вхождения, insert, remove, extend, size, capacity.
И вот надо каждую относительно другой проверять.
Только это выходит (9 - 1)^2 тестов. Помимо остальных, уже реализованных.
у меня проверка на значения только в операциях поиска относительно вставки, то бишь, нашелся ли в многопоточном исполнении элемент, или нет.
относительно удаления проверять - это муторно, потому что после удаления на той же позиции встает соседняя пара, и это случайно, проверено
экспериментально.
Сойдет ли просто проверять время блокировки (shared_lock, и lock_guard)
каждого параллельного текущему потоку относительно времени блокировки\старта\окончания блокировки текущего?
кроме связки (access - insert)?
Тем более, что операции записи\чтения проверяются в немногопоточном исполнении?
А то так замаюсь разгребать эти 8^2 тестов.
https://www.sqlite.org/testing.html
https://assets.amuniversal.com/c8253cc0db9a012e2fae00163e41dd5b
То выходит, что я напишу тесты для std-шных классов блокировки и shared мьютексов.
и все остальное в таком-же духе
Поток выполнится в любом случае.
Моя реализация соответствует unordered_multimap.
> Написать хеш таблицу с открытой адресацией. Главное качество, а не скорость, сказали.
Там многопоточность-то в тестовом задании точно была?
Я в плюсах нихуя не соображаю, но зачем мьютексы, если можно всё реализовать на optimistic locking?
тебе нужно не декартово произведение тестов, а просто несколько тредов, которые по-всякому трахают хэшмапу, а в конце проверяются инварианты.
Только всё равно ж я просто предлагаю ему нормальное решение для того что он делает, а не гарантирую что-то
велика вероятность того, что рано или поздно он найдет проблему
да
Привет, Борманд!