Я просто прокомментировал ситуацию, в отрыве от основной темы топика.
А по теме, как я уже сказал — у меня достаточно сложное отношение.
Во-первых, создатели контента — неважно какого, тоже хотят кушать, и это понятно. Во-вторых, созданный контент нужно продвигать, и те, кто это делают тоже хотят кушать. Но, с другой стороны, ситуация, которая сложилась в сфере авторских прав, явно перекошена в сторону правообладателей и весьма далека от здравого смысла. В частности, мне кажется, было бы хорошо, если бы имущественные права на софт охранялись 3-4-5 лет, а после этого исходники открывались и он бы переходил в частичный опенсорс, в котором его можно раздавать и модифицировать бесплатно, а за прибыль на основе этого софта отчислять процент изначальному автору. Как-то так.
Извините, а это тут к чему? У меня достаточно сложное отношение к вопросам интеллектуальной собственности, но в данном случае я рассматривал конкретную ситуацию, приведённую mclander.
<сарказм>
Конечно нет, нужно бить смертным боем даже за то, что дерзко посмотрели! </сарказм>
Во-первых, хамство, это достаточно условное понятие, для гопника с района — хамство это ни дать закурить. Во-вторых, люди, как существа цивилизованные, должны пытаться решать конфликты прежде всего словесно, а не как обезьяны: у кого больше кулак — тот и прав.
История ни к селу, ни к городу.
Во-втором случае было посягательство на ваше имущество — в таком случаи приминение насилия вполне обоснованно. В первом же случае — вы намеревались завязать потасовку, просто ввиду того, что вы несогласны с чужой точкой зрени, пусть даже трижды убогой.
Именно это я называю, прибегать в споре к кулакам, в качестве аргументов.
if (!file_util::Delete(db_name, false) &&
!file_util::Delete(db_name, false))
Очень странное представление о красивом коде. Если файл не удалился, но есть подозрение что он может удалится позже — нужно создать очередь для отложенного удаления.
Тут вы попали пальцем в небо, я как раз работаю над разработкой системы критичной к отказам. И единственным правильным способом сохранить данные — это периодически сбрасывать их на диск, и восстанавливаться из них. если работа системы не была завершена штатно. Чаще всего, намного лучше потерять данные за какой-то не продолжит промежуток времени, чем рисковать нем, что данные окажутся в результате неверными.
По поводу «не знать» и «забыл»
при грамотном дизайне, стараются избегать не очевидных конструкций, в которых нужно обязательно что-то «знать» и «не забывать»
Что вы подразумеваете под обращения осуществляются при помощи транзакций?
Вот есть общий ресурс, который содержит поля «A» и «B», вы физически не сможете изменить их одновременно, то есть возможна ситуация:
1) поле «A» изменено
2) поток завис
3) поток убит
4) поле «B» — не изменено
5) поля находятся в несогласованном состоянии.
Или ещё пример, вы меняете какую-либо строку, и в этот момент поток уничтожается — результат непредсказуем. В лучшем случаи будет падение, в худшем — будут сохранены неверные данные.
Если вы пишите небольшую улиту, над кодом которой будете работать только вы — то, может быть, и так. Но, как правило, над этим кодом будут работать и другие люди, которые могут не знать всех не очевидных тонкостей работы с этим кодом. Более того, сегодня вы пишете этот код, помня про его особенности, но если через год вы решите внести незначительное изменение, то совсем не факт что вы вспомните про это особенность. Как самый очевидный пример — поток нельзя убивать, даже если он просто выделяет динамическую память.
Можно конечно. Программирование такая штука, когда одну и ту же вещь можно сделать большим числом способов. Только данном случае нужно будет дополнительно создать хэндел для каждого разделяемого ресурса, потом удалить его. А так в целом то-же самое. У меня, правда, есть подозрение, что мой вариант будет работать несколько быстрее, хотя я могу и ошибаться.
Не совсем так. Как я уже писал, smth.wait() — это, по сути, вызов
smth.unlock();
smth.waitPulst();
smth.lock();
То-есть, после сигнала поток проснётся, но не начнёт своё выполнение, пока первый поток не освободит mutex.
Ну, во первых — WaitForMultipleObjects это платформозависимая функция, а паттерн создан с претензией на независимость от реализации, именно по этому всё, что касается непосредственно работы с API вынесено в отдельную стратегию. Далее, основная идея паттерна, собственно, за ради чего он был написан — это блокировка ресурсов, необходимых на данном этапе выполнения единым пакетом, и отслеживание ситуаций, когда это не так. Конечно, можно эту логику реализовать и через WaitForMultipleObjects, но мой вариант кажется несколько проще и определённо удобнее.
Не совсем понял в чём проблема. Доступ к общим данным происходит в области кода, закрытого mutex-ом.
Далее, VenomBlood немного ошибся, smth.wait() это скорее
smth.unlock();
smth.waitPulst();
smth.lock();
по крайней мере, на такую реализацию рассчитывал, возможно этот момент стоило поподробнее расписать.
Я не говорил, что это нельзя делать, я только сказал, что это не очень хорошая практика. Какой смысл расшаривать ресурс между потоками, если фактически он монопольно используется одним из них?
В моей реализации стратегии синхронизации, в классе содержатся 2 объекта: один omni::mutex и один связанный с ним omni::condition, которые используются всеми потоками. wait — метод у condition, lock — метод у mutex.
Опасная практика.
Вы знаете, что это за поток, но вы не имеете представления, какой ассемблерный код сгенерировал компилятор для вашего потока. Когда вы попытаетесь остановить поток — вы не будете иметь не малейшего понятия, на какой именно ассемблерной инструкции он остановится, и что именно он запишет в общие данные.
Я это и имел ввиду. Логика функции очень проста, и в случае наличия хотя-бы 2-х ресурсов в списке, будет работать быстрее, чем вызов mutex::lock для каждого ресурса отдельно.
Есть случаи, когда надо захватить ресурс на все время выполнения задачи, а оно может составлять несколько секунд
Именно для таких ресурсов, захват которых осуществляется на длительное время и предназначен асинхронный lock. Далее, в общем случаи блокировка shared данных на длительное время не есть гуд, так как они на то и общее, что подразумевают использование из разных потоков.
Отлично — что происходит при выполнении метода lock
При выполнении метода lock происходит попытка заблокировать ресурсы, перечисленные в списке, в случае, если не все ресурсы доступны то поток или засыпает, или возвращает false. Кроме того, происходит проверка, не попытался ли этот конкретный поток заблокировать ресурсы, не освободив перед этим предыдущие.
SynchronizationManager блокируется не на время захвата ресурса, а только в момент выполнения функций lock и unlock. Логика их тривиальна, и выполнение не займёт много времени.
А по теме, как я уже сказал — у меня достаточно сложное отношение.
Во-первых, создатели контента — неважно какого, тоже хотят кушать, и это понятно. Во-вторых, созданный контент нужно продвигать, и те, кто это делают тоже хотят кушать. Но, с другой стороны, ситуация, которая сложилась в сфере авторских прав, явно перекошена в сторону правообладателей и весьма далека от здравого смысла. В частности, мне кажется, было бы хорошо, если бы имущественные права на софт охранялись 3-4-5 лет, а после этого исходники открывались и он бы переходил в частичный опенсорс, в котором его можно раздавать и модифицировать бесплатно, а за прибыль на основе этого софта отчислять процент изначальному автору. Как-то так.
<сарказм>Конечно нет, нужно бить смертным боем даже за то, что дерзко посмотрели!
</сарказм>Во-первых, хамство, это достаточно условное понятие, для гопника с района — хамство это ни дать закурить. Во-вторых, люди, как существа цивилизованные, должны пытаться решать конфликты прежде всего словесно, а не как обезьяны: у кого больше кулак — тот и прав.
Во-втором случае было посягательство на ваше имущество — в таком случаи приминение насилия вполне обоснованно. В первом же случае — вы намеревались завязать потасовку, просто ввиду того, что вы несогласны с чужой точкой зрени, пусть даже трижды убогой.
Именно это я называю, прибегать в споре к кулакам, в качестве аргументов.
Очень странное представление о красивом коде. Если файл не удалился, но есть подозрение что он может удалится позже — нужно создать очередь для отложенного удаления.
при грамотном дизайне, стараются избегать не очевидных конструкций, в которых нужно обязательно что-то «знать» и «не забывать»
Вот есть общий ресурс, который содержит поля «A» и «B», вы физически не сможете изменить их одновременно, то есть возможна ситуация:
1) поле «A» изменено
2) поток завис
3) поток убит
4) поле «B» — не изменено
5) поля находятся в несогласованном состоянии.
Или ещё пример, вы меняете какую-либо строку, и в этот момент поток уничтожается — результат непредсказуем. В лучшем случаи будет падение, в худшем — будут сохранены неверные данные.
smth.unlock();
smth.waitPulst();
smth.lock();
То-есть, после сигнала поток проснётся, но не начнёт своё выполнение, пока первый поток не освободит mutex.
Далее, VenomBlood немного ошибся, smth.wait() это скорее
smth.unlock();
smth.waitPulst();
smth.lock();
по крайней мере, на такую реализацию рассчитывал, возможно этот момент стоило поподробнее расписать.
В моей реализации стратегии синхронизации, в классе содержатся 2 объекта: один omni::mutex и один связанный с ним omni::condition, которые используются всеми потоками. wait — метод у condition, lock — метод у mutex.
Вы знаете, что это за поток, но вы не имеете представления, какой ассемблерный код сгенерировал компилятор для вашего потока. Когда вы попытаетесь остановить поток — вы не будете иметь не малейшего понятия, на какой именно ассемблерной инструкции он остановится, и что именно он запишет в общие данные.
При выполнении метода lock происходит попытка заблокировать ресурсы, перечисленные в списке, в случае, если не все ресурсы доступны то поток или засыпает, или возвращает false. Кроме того, происходит проверка, не попытался ли этот конкретный поток заблокировать ресурсы, не освободив перед этим предыдущие.