и совсем забил на чтение статьи сосредоточившись на коде.
Ну как раз в коде это и учитывается как случай отсутствия пересечения.
Никогда бы не подумал, что бывают люди, считающие совпадающие отрезки непересекающимися…
А что в этом такого? А еще бывает такое что конечная точка отрезка вообще в отрезок не входит, смотря какой отрезок. Если Вы математику помните, то обозначения вроде (a, b), [a, b], и их комбинации Вам что-то об этом должны напомнить.
Скажите, а вы всегда плавучку сравниваете при помощи ==?
Я понимаю о чём вы, но в данном случае учет погрешности смысла не имеет — если Z даже незначительно больше или меньше нуля, он учтется в ветке, где сравниваются знаки.
Спасибо огромное за ценные указания =)
Но видимо, простите, чукча не читатель, чукча писатель? =)
У меня отдельно разобран случай где векторные произведения нулевые, и указано, что считать это пересечением или нет — дело каждого. В моей конкретной реализации этот пограничный случай пересечением не считается.
Ну в некотором смысле да. Но это всё зависит от среды. Например в java или .net в принципе не может возникнуть этой проблемы.
Ну да, поэтому я и написал — в языке С.
Задача, которая решается, сформулирована в начале статьи — иметь гарантии _именно_в_многопоточном_ приложении — того, что структура или участок памяти на который мы ссылаемся — живой.
Я понимаю, что хендлы помогли решить какую-то вашу проблему с многопочностью.
Я даже ОПИСАЛ, какую. И не только хэндлы, а и интрузивные указатели тоже.
Как вы планируете бороться с переполнением версии?
Я не планирую с ней бороться. Практически при переполнении версии случай коллизии практически невероятен, если вы конечно не используете под неё unsigned char. Всё что больше этого даёт достаточно четкие гарантии.
Но поднятый вопрос понят, и, что называется acknowledged.
Ну вот это как раз одно из важнейших условий консистентности объекта.
И для того чтобы воспользоваться одним из примитивов синхронизации, тем же мьютексом, желательно сначала установить насколько он сам-то вообще живой.
но ваша постановка задачи неверна. И поэтому вы сделали неверные выводы в конце статьи
А что конкретно вам не понравилось в постановке задачи? Я от вас из критики услышал только то, что «управление циклом жизни объекта ортогонально многопоточности».
И что показалось неверным в выводах, которые, я считаю, довольно очевидны? Ну кроме, возможно, упомянутого вами минуса, который действительно как минус довольно спорен?
Мммм, какое преимущество хэндлы имеют именно в многопоточных приложениях? Я прочитал вашу статью, комментарии, но так и не понял.
Ну тогда извините.
Вы о том примере с передачей объекта между потоками? Не покажете пример кода как гарантировано передать объект между двумя потоками с использованием хендлов? При условии, что в вызывающем потоке этот объект больше не нужен?
Этот пример совсем не о гарантии существования объекта. Но вы уже написали, что не поняли. Чем помочь уже не знаю.
Правильное использование handle не вызовет ошибки обращения к памяти.
Правильное использование тупого счетчика ссылок тоже не вызовет ошибок обращения к памяти.
Ну вот, мы уже почти там.
Handle невозможно использовать по назначению так чтобы вызвать ошибку обращения к памяти. Если вы забыли проверить на NULL в бэктрейсе дампа вы это сразу увидите.
С тупым счетчиком ссылок это всё же возможно. При этом ошибку вы можете увидеть далеко не сразу при обращении к памяти, а гораздо, гораздо позже.
Извините, но в данном случае не рассматривается общий доступ к памяти.
Гарантия безошибочности чтения и записи в выделенный кусок памяти — это не доступ?
Проблема ABA с хэндлами — это не доступ?
Давайте не заниматься придирками и безудержным критиканством.
Но случаев когда нужна именно strong refference всё же больше, разве нет?
Как ни странно, случаев когда нужны именно strong reference у меня как раз меньше. Как правило один объект или трэд порождает объект, он им и владеет и занимается. А другие потоки им только пользуются по мере надобности.
Ну да, циклические зависимости — это как раз то место где и нужен weak ptr. Общий на всю систему сокет — это не то место, где нужен weak ptr.
А сокет-то тут причём? Вы что, сокет решили счётчиками считать?
Я говорил о других объектах с которыми может идти манипуляция после вычитывания данных.
Просто как я говорил понятие владения довольно ортогонально к многопоточности.
Давайте обойдемся без пустого критиканства, хорошо? Понятие «алгоритм» тоже «ортогонально» к понятию «программирование».
кроме «атомарного» volatile и одного натянутого примера
И без передёргивания понятий, если можно. volatile — это спецификация переменной, а «атомарный» — доступ к ним. В любом приложении хорошим тоном является обозначение с помощью volatile тех переменных которые изменяются более чем в одном потоке, и изменения которых важны для состояния.
на самом деле. Вам ещё нужен мютекс на пул
Возможно вы заметили, что вопроса организации собственно пула я не касался. И думаю что вам так же как мне известно, что давно уже существует порядочное количество lock-free алгоритмов для почти любых контейнеров.
Что в статье есть такого (кроме «атомарного» volatile и одного натянутого примера), что имеет какое-либо отношение к многопоточности?
Вот именно этот пример весьма характерен именно для многопоточных приложений. Не конкретно он, а проблема доступа к освобожденной памяти. В однопоточном приложении счётчика ссылок более чем достаточно для определения времени жизни объекта. И хэндлы в однопоточном приложении не нужны.
Тем не менее в этой ситуации у handle нет никаких преимуществ перед обычным встроенным счётчиком ссылок. И там и там надо делать ref() в вызывающем потоке. Поэтому я не понимаю, зачем вы приводили этот пример.
В данной ситуации (в первой, там где ошибка) у handle есть одно огромное преимущество: он не вызовет ошибок обращения к памяти.
Потому что вы путаете понятие общего доступа и общего владения.
Общее владение это общее владение. Общий доступ — это общий доступ. В данном случае рассматривается общий доступ к памяти. Общее владение тут указано как один из способов гарантировать сохранность выделенного участка памяти.
Вы предлагаете использовать ваш handle именно в режиме weak refference, т.е. отпускать ссылку сразу после использования и потом молиться, что кто-то ещё держит этот сокет, что бы вы могли взять ссылку ещё раз.
Я предлагаю использовать хэндл именно в режиме weak reference, т.е. ссылки на объект, а не владение объектом. В моей практике есть десятки случаев когда нужен именно weak reference.
Например, предложите мне другой способ избежать циркулярных зависимостей.
В данном случае нет никакой разницы между однопоточной и многопоточной средой. Собственно проблема совместного владения объектами (а вы решаете именно её) довольно таки ортогональна многопоточности. По большему счету, для поддержки многопоточности надо просто решить проблему атомарности счётчика ссылок.
Поймите меня правильно, я совсем не против того чтобы вы или кто-то другой использовал указанные примитивы для однопоточных приложений. Но в данной статье я рассматриваю их конкретно в применении к многопоточности, что и указано в заголовке.
Проблема общего доступа к данным решается с помощью примитивов синхронизации (мютексов, например).
Я с удовольствием прочитаю если вы расскажете как решить описанную мной проблему с помощью примитивов синхронизации.
Вам надо или залочить его в первом треде или с вероятностью 50% вы получите null во втором треде. Конечно, опасной ситуации это не создаст, но и объекта вы не получите. Толку от такой надежности?
Рассмотренная ситуация является утрированной, разумеется никто и никогда так не делает. Это лишь иллюстрация того, каким образом неаккуратное использование встроенных счётчиков ссылок может легко привести к проблемам с памятью. В случае с хэндлами подобные проблемы с памятью исключены.
Хм, а как это «временно не требуется»?
Ну например объект требуется только во время каких-то операций, занимающих конечное время (чтение из сокета при наличии данных, к примеру). В остальных случаях доступ к объекту не требуется.
В однопоточной среде описанные проблемы решаются гораздо проще, а ещё в однопоточной среде гораздо проще такие проблемы не создавать в принципе.
В данном случае рассматривается применение именно в многопоточной среде, потому что именно в многопоточной среде проблема одновременного общего доступа к данным наиболее актуальна.
Хэндл решает проблему передачи объекта между потоками в том плане, что передав в поток хэндл мы всегда можем попробовать залочить объект и убедиться в том что он жив, или же понять, что объект уже умер не создавая опасных ситуаций (см. пример 1 с обращением к освобожденной памяти).
Согласен, это нормальное поведение strong reference, поэтому это минус не конкретного подхода, а в принципе техники сильных ссылок. Пожалуй я неправильно сформулировал в чём заключается минус. Минус в том что мы не можем произвольно освобождать объект на время а потом пытаться залочить вновь, если он временно не требуется.
Да, счётчик ссылок предполагается атомарным, и по сути он volatile. Да, Вы правы, в gcc атомарный доступ будет работать правильно при любой оптимизации и без volatile, но я не готов отвечать за другие компиляторы. Про version в weak_handle_s — это тоже верно заметили: если на совесть, там тоже должен стоять volatile.
Ну как раз в коде это и учитывается как случай отсутствия пересечения.
А что в этом такого? А еще бывает такое что конечная точка отрезка вообще в отрезок не входит, смотря какой отрезок. Если Вы математику помните, то обозначения вроде (a, b), [a, b], и их комбинации Вам что-то об этом должны напомнить.
Я понимаю о чём вы, но в данном случае учет погрешности смысла не имеет — если Z даже незначительно больше или меньше нуля, он учтется в ветке, где сравниваются знаки.
Ну и выпускник я лет уж как 10.
Но видимо, простите, чукча не читатель, чукча писатель? =)
У меня отдельно разобран случай где векторные произведения нулевые, и указано, что считать это пересечением или нет — дело каждого. В моей конкретной реализации этот пограничный случай пересечением не считается.
Ну да, поэтому я и написал — в языке С.
Задача, которая решается, сформулирована в начале статьи — иметь гарантии _именно_в_многопоточном_ приложении — того, что структура или участок памяти на который мы ссылаемся — живой.
Я даже ОПИСАЛ, какую. И не только хэндлы, а и интрузивные указатели тоже.
Я не планирую с ней бороться. Практически при переполнении версии случай коллизии практически невероятен, если вы конечно не используете под неё unsigned char. Всё что больше этого даёт достаточно четкие гарантии.
Но поднятый вопрос понят, и, что называется acknowledged.
Ну вот это как раз одно из важнейших условий консистентности объекта.
И для того чтобы воспользоваться одним из примитивов синхронизации, тем же мьютексом, желательно сначала установить насколько он сам-то вообще живой.
А что конкретно вам не понравилось в постановке задачи? Я от вас из критики услышал только то, что «управление циклом жизни объекта ортогонально многопоточности».
И что показалось неверным в выводах, которые, я считаю, довольно очевидны? Ну кроме, возможно, упомянутого вами минуса, который действительно как минус довольно спорен?
Ну тогда извините.
Этот пример совсем не о гарантии существования объекта. Но вы уже написали, что не поняли. Чем помочь уже не знаю.
Ну вот, мы уже почти там.
Handle невозможно использовать по назначению так чтобы вызвать ошибку обращения к памяти. Если вы забыли проверить на NULL в бэктрейсе дампа вы это сразу увидите.
С тупым счетчиком ссылок это всё же возможно. При этом ошибку вы можете увидеть далеко не сразу при обращении к памяти, а гораздо, гораздо позже.
Гарантия безошибочности чтения и записи в выделенный кусок памяти — это не доступ?
Проблема ABA с хэндлами — это не доступ?
Давайте не заниматься придирками и безудержным критиканством.
Как ни странно, случаев когда нужны именно strong reference у меня как раз меньше. Как правило один объект или трэд порождает объект, он им и владеет и занимается. А другие потоки им только пользуются по мере надобности.
А сокет-то тут причём? Вы что, сокет решили счётчиками считать?
Я говорил о других объектах с которыми может идти манипуляция после вычитывания данных.
Давайте обойдемся без пустого критиканства, хорошо? Понятие «алгоритм» тоже «ортогонально» к понятию «программирование».
И без передёргивания понятий, если можно. volatile — это спецификация переменной, а «атомарный» — доступ к ним. В любом приложении хорошим тоном является обозначение с помощью volatile тех переменных которые изменяются более чем в одном потоке, и изменения которых важны для состояния.
Возможно вы заметили, что вопроса организации собственно пула я не касался. И думаю что вам так же как мне известно, что давно уже существует порядочное количество lock-free алгоритмов для почти любых контейнеров.
Вот именно этот пример весьма характерен именно для многопоточных приложений. Не конкретно он, а проблема доступа к освобожденной памяти. В однопоточном приложении счётчика ссылок более чем достаточно для определения времени жизни объекта. И хэндлы в однопоточном приложении не нужны.
В данной ситуации (в первой, там где ошибка) у handle есть одно огромное преимущество: он не вызовет ошибок обращения к памяти.
Общее владение это общее владение. Общий доступ — это общий доступ. В данном случае рассматривается общий доступ к памяти. Общее владение тут указано как один из способов гарантировать сохранность выделенного участка памяти.
Я предлагаю использовать хэндл именно в режиме weak reference, т.е. ссылки на объект, а не владение объектом. В моей практике есть десятки случаев когда нужен именно weak reference.
Например, предложите мне другой способ избежать циркулярных зависимостей.
Поймите меня правильно, я совсем не против того чтобы вы или кто-то другой использовал указанные примитивы для однопоточных приложений. Но в данной статье я рассматриваю их конкретно в применении к многопоточности, что и указано в заголовке.
Я с удовольствием прочитаю если вы расскажете как решить описанную мной проблему с помощью примитивов синхронизации.
Рассмотренная ситуация является утрированной, разумеется никто и никогда так не делает. Это лишь иллюстрация того, каким образом неаккуратное использование встроенных счётчиков ссылок может легко привести к проблемам с памятью. В случае с хэндлами подобные проблемы с памятью исключены.
Ну например объект требуется только во время каких-то операций, занимающих конечное время (чтение из сокета при наличии данных, к примеру). В остальных случаях доступ к объекту не требуется.
В данном случае рассматривается применение именно в многопоточной среде, потому что именно в многопоточной среде проблема одновременного общего доступа к данным наиболее актуальна.
Хэндл решает проблему передачи объекта между потоками в том плане, что передав в поток хэндл мы всегда можем попробовать залочить объект и убедиться в том что он жив, или же понять, что объект уже умер не создавая опасных ситуаций (см. пример 1 с обращением к освобожденной памяти).
Согласен, это нормальное поведение strong reference, поэтому это минус не конкретного подхода, а в принципе техники сильных ссылок. Пожалуй я неправильно сформулировал в чём заключается минус. Минус в том что мы не можем произвольно освобождать объект на время а потом пытаться залочить вновь, если он временно не требуется.