если нет дедлоков (с чего весь разговор и начался), то использование конструкции
lock(queue){queue.add(myObj)}
гарантирует, что вставка завершится. асинхронные же сокеты вряд ли могут служить тут хоть какой-нибудь аналогией, поскольку там и цели другие, и принципы работы, и вообще всё. из моей логики, заключающейся в том, что вставка валидного объекта в валидную очередь, возвращающая FAIL - это хуёвый дизайн, ненужность асинхронного ввода-вывода никак не следует.
далее, lock() процессор не ест, так что "поделать что-нибудь другое" могут остальные треды. а наш занят тем, что в очередь вставляет. вы представляете себе, насколько это решение с FAIL усложняет код, пользующийся такой "очередью"?
Locking - очень медленная операция. Ее хочется избежать. Насколько я понимаю ограничения этой задачки - systems programming как-никак, тормозить нельзя - malloc тоже хочется по мере возможности избегать. Если malloc запрещен вообще, то волей-неволей иногда придется возвращать FAIL.
Если очень хочется, можно попробовать сейчас придумать вариант получше. Граничные условия:
1) по минимуму malloc 2) нет locking 3) не возвращается FAIL на put 4) более-менее линейное расположение данных в памяти
У меня что-то пока не очень получается. Впрочем, я вообще не слишком умный.
ну, malloc надо просто делать каждый раз жаднее в два раза. а линейное - это уж как memory manager даст. я вообще на сишарпе пишу, так что никаких маллоков :-)
Эта идея сразу приходит. Маллок маллоком, но как предлагается данные на новое место двигать, не используя lock? А если он используется в put, то в get мы будем уже вынуждены его использовать.
У меня вопрос off-topic. Скажите, а Вы на C# пишете потому что нравится или потому что corporate policy? Если "нравится", то почему? Если corporate policy, то почему? Это не flamebait, сам я ничо рекламировать не хочу, просто интересно.
нравится. отличия от С++ и Дельфи очевидны (хотя я могу остановиться на них поподробнее, если вам интересно). почему не на джаве - объяснить труднее, но к джаве у меня стойкое отвращение. не к джаве как языку, собственно, а к тому, что вокруг. ни одной IDE приемлемой для джавы я не видел (хотя вот IDEA-ю хвалят, но теперь уж поздно на неё смотреть). да и вообще... куча мелочей в джаве раздражает, а те же мелочи в дотнете сделаны по уму, и это приятно.
Хочется представить себе, какая будет экосистема вокруг CLR лет через пять. Самому мне в это, надеюсь, лезть не придется, а посмотреть со стороны интересно.
оно улучшается стремительным домкратом, куда быстрее, чем джава. новая Visual Studio - это просто песня. они даже украли у меня пару архитектурных решений и захардкодили их :-)
Я смотрю не с точки зрения разработки - я слышал, там действительно рай для разработчика. Я пытаюсь смотреть с точки зрения экосистемы. Меня слегка пугает идея "платформы .Net".
Например, если я пишу сервлеты на Java, то я могу выбирать из кучи серверов (многие из которых open source), соответствующих спецификации Servlet.
А Майкрософт, похоже, меньше делает упор на "спецификации" и больше на "реализацию" - мне предлагается доверять их реализациям и принимать на веру обещания насчет обратной совместимости.
JDBC - это сановская спецификация на драйверы. Не реализация.
J2EE - это спецификация. У нее есть, например, open source реализация JBoss.
Аналогично - JMX, Servlets/JSP и так далее. Есть не-сановские компиляторы Java. Есть не-сановские IDE. Есть не-сановские библиотеки, которые стали де-факто стандартом - например, log4j.
Модель Sun: выпустить spec и reference implementation. Модель Microsoft - выпустить реализацию, которая сама по себе является spec.
сановская модель хороша только в теории. на практике получается, что спецификации описывают не всё и мы имеем, например, implementation-specific deployment descriptors, что делает процесс перехода, например, с JBOSS на Weblogic невыносимо болезненным. спецификация сервлетов - это вообще просто набор интерфейсов, дотнет в этом плане ничем не хуже. ну и, наконец, девелоперу с майкрософтовскими продуктами работать в основном удобно, а с продуктами open source в основном неудобно. чтобы понять, почему, достаточно задуматься над силами, движущими майкрософтовским девелопером и опенсорсным девелопером.
тьфу, опять повёлся на дискуссию о победе разума над здравым смыслом.
Очередь с одним писателем - это типичный случай. Более того, когда писатель один и читатель один - это тоже типичный случай, внутри первого типичного случая.
Конечно, если о скорости не беспокоиться, можно на уровне системы реализовать (например) process pipe, которая будет лочиться на каждое чтение/запись. Тогда эти локи и будут ограничивающим фактором для
Rewriting get() to be safe for multiaccess. We need to isolate getPoint and update it successfully. This implies we need to synchronize the get() function on getPoint, and synchronize the put() function on putPoint. They should not both synchronize on the same monitor, as this may result in processes missing a relevant notify.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2005-01-18 12:23 pm (UTC)lock(queue){queue.add(myObj)}гарантирует, что вставка завершится. асинхронные же сокеты вряд ли могут служить тут хоть какой-нибудь аналогией, поскольку там и цели другие, и принципы работы, и вообще всё. из моей логики, заключающейся в том, что вставка валидного объекта в валидную очередь, возвращающая FAIL - это хуёвый дизайн, ненужность асинхронного ввода-вывода никак не следует.далее, lock() процессор не ест, так что "поделать что-нибудь другое" могут остальные треды. а наш занят тем, что в очередь вставляет. вы представляете себе, насколько это решение с FAIL усложняет код, пользующийся такой "очередью"?
(no subject)
Date: 2005-01-18 12:40 pm (UTC)Если очень хочется, можно попробовать сейчас придумать вариант получше. Граничные условия:
1) по минимуму malloc
2) нет locking
3) не возвращается FAIL на put
4) более-менее линейное расположение данных в памяти
У меня что-то пока не очень получается. Впрочем, я вообще не слишком умный.
(no subject)
Date: 2005-01-18 01:12 pm (UTC)(no subject)
Date: 2005-01-18 01:16 pm (UTC)(no subject)
Date: 2005-01-18 01:33 pm (UTC)(no subject)
Date: 2005-01-18 02:01 pm (UTC)(no subject)
Date: 2005-01-19 01:24 am (UTC)(no subject)
Date: 2005-01-19 05:47 am (UTC)(no subject)
Date: 2005-01-19 12:36 pm (UTC)(no subject)
Date: 2005-01-19 01:41 pm (UTC)(no subject)
Date: 2005-01-19 02:17 pm (UTC)Например, если я пишу сервлеты на Java, то я могу выбирать из кучи серверов (многие из которых open source), соответствующих спецификации Servlet.
А Майкрософт, похоже, меньше делает упор на "спецификации" и больше на "реализацию" - мне предлагается доверять их реализациям и принимать на веру обещания насчет обратной совместимости.
Аналогичная ситуация с JDBC и так далее.
(no subject)
Date: 2005-01-20 07:44 am (UTC)(no subject)
Date: 2005-01-20 11:23 am (UTC)J2EE - это спецификация. У нее есть, например, open source реализация JBoss.
Аналогично - JMX, Servlets/JSP и так далее. Есть не-сановские компиляторы Java. Есть не-сановские IDE. Есть не-сановские библиотеки, которые стали де-факто стандартом - например, log4j.
Модель Sun: выпустить spec и reference implementation. Модель Microsoft - выпустить реализацию, которая сама по себе является spec.
(no subject)
Date: 2005-01-20 11:47 am (UTC)сановская модель хороша только в теории. на практике получается, что спецификации описывают не всё и мы имеем, например, implementation-specific deployment descriptors, что делает процесс перехода, например, с JBOSS на Weblogic невыносимо болезненным. спецификация сервлетов - это вообще просто набор интерфейсов, дотнет в этом плане ничем не хуже. ну и, наконец, девелоперу с майкрософтовскими продуктами работать в основном удобно, а с продуктами open source в основном неудобно. чтобы понять, почему, достаточно задуматься над силами, движущими майкрософтовским девелопером и опенсорсным девелопером.
тьфу, опять повёлся на дискуссию о победе разума над здравым смыслом.
(no subject)
Date: 2005-01-20 03:48 pm (UTC)(no subject)
Date: 2005-01-18 12:50 pm (UTC)гарантирует, что вставка завершится.
Зато при Вашем подходе писатель может заставить читателя голодать вечно. Понимаю, что nitpick, но все же =))
(no subject)
Date: 2005-01-18 01:07 pm (UTC)при внимательном перечтении статьи обнаружилось, что это вообще будет работать для только одного писателя и только одного читателя. неинтересно.
(no subject)
Date: 2005-01-18 01:15 pm (UTC)Очередь с одним писателем - это типичный случай. Более того, когда писатель один и читатель один - это тоже типичный случай, внутри первого типичного случая.
Конечно, если о скорости не беспокоиться, можно на уровне системы реализовать (например) process pipe, которая будет лочиться на каждое чтение/запись. Тогда эти локи и будут ограничивающим фактором для
ls -l | grep "ляля" | more
или тому подобной фигни...
Впрочем, на вкус и цвет товарищей нет =)
(no subject)
Date: 2005-01-18 01:25 pm (UTC)(no subject)
Date: 2005-01-18 01:27 pm (UTC)Rewriting get() to be safe for multiaccess. We need to isolate getPoint and update it successfully. This implies we need to synchronize the get() function on getPoint, and synchronize the put() function on putPoint. They should not both synchronize on the same monitor, as this may result in processes missing a relevant notify.