| 12:04a |
задумался в 125-й раз над философским вопросом - как писать ассерты в программах?
проблема тут такая, что с точки зрения девелопмента программа должна дохнуть на самом первом же ассерте, бескомпромиссно побуждая программиста её чинить.
С другой же стороны, с точки зрения надежности продукта ассерты желательно превращать в исключения или коды ошибок и вырубать ошибочно сработавшие куски функциональности. Грубо говоря, если у вас есть сервер, или программа редактирования изображений, то ронять её от какого-то там ассершена - практика очень сомнительная.
Вы мне можете сказать, а мол не офигел ли я ассершены в продакшн код ставить, но офигел не только я - например класс promise в С++ спокойно себе кидает исключения при неправильном его использовании. Ну и вообще, чего б ассершнам не быть в некотором объеме в продакшн-коде, кстати? Если они не будут гробить программу а просто прокидывать исключения.
Вот и непонятно мне -- с одной стороны программу надо натаскивать на максимальную живучесть, а с другой - это препятствует обнаружению во-время ошибок, ибо просто так на логи ошибок никто смотреть не будет.
Конечно, тут возможны комбинированные варианты -- например, сделать сообщений о фатальных ошибках максимально заметными программисту, так чтоб мимо пройти нельзя было. Но вот что-то о таких подходах я не слыхал. |
| 5:00p |
поток малосвязного бреда
прочел в одной из лекций, что когерентность кеша обеспечивает всего лишь тотальное упорядочивание операций на каждой отдельной ячейке памяти, но никак не тотальное упорядочивание операций с памятью вообще, с точки зрения того, что происходит уже за пределами процессоров (со своей системой переупорядочивания операций доступа к памяти).
Я до сего дня полагал, что когерентность кеша как раз и означает тотальное упорядочение доступа к памяти (и окружающим её кешам), т.е. то, что наличием кеша, даже и многоуровнего кеша, в многопроцессорной системе в практике программирования можно принебречь.
С другой стороны, наверное, наличием кеша можно действительно пренебречь, поскольку процессорные memory fences, видимо, должны и правильно взаимодействовать с кешами, обеспечивая те или иные гарантии консистентности и на их уровне. Я, опять же, считал, что memory fence действует исключительно внутри данного процессора, даже и до внутренних кешей не доходя.
Всё это происходит от неупорядоченного потребления информации, когда не учишь тему достаточно вглубь, но создаешь себе некоторую модель, достраивая в уме, выдумывая, недостающие детали и считая, что всё уже понимаешь. Как с этим бороться - не очень понятно. Как минимум, усердием в учебе и меньшей самоуверенностью.
Как бы, в результате, действительно, знание всех этих тонкостей для программиста не нужно было бы (хорошая реализация барьера равным образом даст нужный барьер или аналог его и компилятору, и процессору, и кешу, и блокам памяти), если бы не одно но: неупорядоченность работы кешей приводит к тому, что нет никакого тотального порядка изменения ячеек памяти - а сие уже надо осознавать и учитывать, если пишешь всерьез код на атомарных объектах. А какие относительно этого нетотального порядка доступа к памяти есть гарантии (скажем, есть ли гарантии транзитивности видимости при использовании барьеров в памяти, не обеспечивающих тотальной упорядоченности) - для меня пока-что загадка (в общем случае).
Если кто-то из читателей разбирается в модели памяти С++11, java или каких-то конкретных архитектур, буду рад комментариям и пояснениям. |