R>Не могу сказать за ядро Windows, но в Linux вот:
...
Дык это все случае, кода надо ходить по списку вообще без блокировки или без блокировки проверить пусто/не пусто и только потом блокировать?
Самому ядерные исходники читать совсем нет желания
Здравствуйте, alsemm, Вы писали:
A>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, alsemm, Вы писали:
A>>>А как прокомментируете утверждение, что ваше решение позволяет вызывать методы класса без блокировки (забыл случайно R>>кто-то lock дернуть, например)?
R>>Да никак не прокомментирую. Я бы так синхронизацию делать не стал.
A>Тогда я не понял, а про что был пример в первом сообщении этой темы?
Если я так не делаю, это не значит, что никто так не делает. Некоторые считают это удобным.
Здравствуйте, alsemm, Вы писали:
R>>Не могу сказать за ядро Windows, но в Linux вот: A>... A>Дык это все случае, кода надо ходить по списку вообще без блокировки или без блокировки проверить пусто/не пусто и только потом блокировать?
Когда ходить по списку вообще без блокировки. В Microsoft тоже так хотят — но всё запатентовано, поэтому приходится довольствоваться только проверкой на пустоту
Одним словом, "извращённые" методы синхронизации рулят
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, alsemm, Вы писали:
A>>поделитесь знанием про хотя бы пару ядерных списков, которые: A>>1. обычно пустые; A>>2. проверять их на наличие элементов надо таким хитрым способом; A>>3. проверки делать надо очень часто.
GN>"Обычно" и "очень часто" — это неопределённые величины. Есть, например, правило: "Minimizing the time that a driver holds spin locks can significantly improve both the performance of the driver and of the system overall".
"Обычно" — в > 50% обращений;
"очень часто" — скажем каждые 50мс.
Если надо список лочить, то куда ж вы денетесь-то Если список в > 50% обращений к нему пустой, то оптимизация имеет смысл. Если нет — толку от нее мало, все равно вам хватать spin lock или чего там еще.
...
GN>Поэтому возможность тонко управлять локами — важна. Возможность при этом использовать С++ обёртки — еще важнее, учитывая классическую ошибку:
GN>
GN>if ( some )
GN> p = RemoveHeadList(&list_head);
GN>/*
GN> #define RemoveHeadList(ListHead) \
GN> (ListHead)->Flink;\
GN> {RemoveEntryList((ListHead)->Flink)}
GN>*/
GN>
У этой ошибки я вижу две причины:
1. кривое объявление ядерного макроса — ну что ж поделать, косяки у всех бывают;
2. лень драйверописателей писать
if ( some )
{
foo();
}
вместо
if ( some )
foo();
А на чем сейчас ядра пишут? Мне всегда казалось, что как и сто лет назад на голом C Ядрописателям все эти шаблонные оберки-припарки до лампочки.
Драйвера открытые тоже, наверное, на С делают, чтоб на всяких экзотических железках работали. А виндовые дрова, наверное, и на C++ делают, гораздо это проще и удобней, не спорю.
Здравствуйте, Andrew S, Вы писали:
E>>>Я так понял, что все проблемы проистекают из неудобного интерыейса объекта синхронизации?
E>>Если так, то, IMHO, лучше всего подумать нужно ли оно нам? E>>А если таки нужно, то я бы отдедельно решал проблему, как сделать интерфейс удобным, и отдельно, как оформить лок из клиентского кода...
AS>Ну а куда деваться... Есть множество библиотек, где гварды реализованы именно как некопируемые объекты. Приходится извращаться AS>В этом плане, конечно, решение remark'а интересно тем, что позволяет делать inplace вызовы без каких-либо нарушений. Но вот если хочется блокирования на более долгий период и при этом сам блокируемый объект не важен (т.е. он используется неявно другими объектами, как, например, OLEDB сессия и команды), тогда без RVO, похоже, не обойтись. С соответствующими последствиями.
В такой ситуации вообще нет проблемы:
class synchronized
{
mutex mtx;
friend class lock;
...
};
class lock
{
noncopyable_scoped_lock l_;
lock(synchronized&)
...
};
class user_class : public synchronized
{
};
int main()
{
user_class x;
lock l (x);
//...
}
Здравствуйте, remark, Вы писали:
R>Здравствуйте, alsemm, Вы писали:
R>>>Не могу сказать за ядро Windows, но в Linux вот: A>>... A>>Дык это все случае, кода надо ходить по списку вообще без блокировки или без блокировки проверить пусто/не пусто и только потом блокировать?
R>Когда ходить по списку вообще без блокировки. В Microsoft тоже так хотят — но всё запатентовано, поэтому приходится довольствоваться только проверкой на пустоту R>Одним словом, "извращённые" методы синхронизации рулят
Вот не думал, что в GPL-ом ядре есть патентованный код. Что за патенты? где про это можно почитать? Было бы очень интересно.
AS>>Ну а куда деваться... Есть множество библиотек, где гварды реализованы именно как некопируемые объекты. Приходится извращаться AS>>В этом плане, конечно, решение remark'а интересно тем, что позволяет делать inplace вызовы без каких-либо нарушений. Но вот если хочется блокирования на более долгий период и при этом сам блокируемый объект не важен (т.е. он используется неявно другими объектами, как, например, OLEDB сессия и команды), тогда без RVO, похоже, не обойтись. С соответствующими последствиями.
R>В такой ситуации вообще нет проблемы:
Как раз проблема есть. Придется писать lock для каждого объекта, что как минимум не комильфо. Решение с RVO позволяет просто пользоваться общей базой и держать возврашаемый объект лока (который уже производного типа) константной ссылкой.
Здравствуйте, Andrew S, Вы писали:
AS>>>Ну а куда деваться... Есть множество библиотек, где гварды реализованы именно как некопируемые объекты. Приходится извращаться AS>>>В этом плане, конечно, решение remark'а интересно тем, что позволяет делать inplace вызовы без каких-либо нарушений. Но вот если хочется блокирования на более долгий период и при этом сам блокируемый объект не важен (т.е. он используется неявно другими объектами, как, например, OLEDB сессия и команды), тогда без RVO, похоже, не обойтись. С соответствующими последствиями.
R>>В такой ситуации вообще нет проблемы:
AS>Как раз проблема есть. Придется писать lock для каждого объекта, что как минимум не комильфо. Решение с RVO позволяет просто пользоваться общей базой и держать возврашаемый объект лока (который уже производного типа) константной ссылкой.
lock зависит только от базового класса synchronized, но не от конкретного пользовательского класса. Т.ч. всё должно быть ОК.
Здравствуйте, alsemm, Вы писали:
A>Если надо список лочить, то куда ж вы денетесь-то Если список в > 50% обращений к нему пустой, то оптимизация имеет смысл. Если нет — толку от нее мало, все равно вам хватать spin lock или чего там еще.
Всё верно для юзерленда, просто в ядре принято очень бережно относиться к ресурсам. К тому же из-за отсутствия понятия "один тред" от тщательного продумывания синхронизации никуда не денешся.
A>У этой ошибки я вижу две причины: A>1. кривое объявление ядерного макроса — ну что ж поделать, косяки у всех бывают;
Это косяк MS, и в общем-то понятно, что не исправляют для совместимости со старыми версиями DDK.
A>2. лень драйверописателей писать A>
A>if ( some )
A>{
A> foo();
A>}
A>
Обычно даже через строчку учат писать
A>А на чем сейчас ядра пишут? Мне всегда казалось, что как и сто лет назад на голом C Ядрописателям все эти шаблонные оберки-припарки до лампочки.
Про *nix не знаю, а MS даже недавно разработанный KMDF реализовали на C. Несмотря на
Реальные пацаны конечно пишут драйвера устройств и фильтры FS на C и сразу без ошибок.
Но сейчас есть острая необходимость в прикладном софте под ядро, например антивирус, что бы уметь действително что-то находить, должен работать напрямую с диском, а сейчас месяцами правятся ошибки 2го порядка из-за треша поинтеров в кривых хуках. И еще надо 2е ядро, что бы это не тормозило работу ОС. А как по-другому то получится, если надо одновременно помнить про 68 ресурсов? Если надо не С с классами, а C++ (те же функторы дают выигрыш в скорости ) — пиши километры кода. boost::? Ну да, не забудем реализовать operator new Так что если какая-то "мелочь" поможет упростить разработку, то это по моему очень хорошо А открытый мютекс можно и в интерфейсе задокументировать, это ерунда после регулярного использования:
//
// Calculate the address of the base of the structure given its type, and an
// address of a field within the structure.
//#define CONTAINING_RECORD(address, type, field) ((type *)( \
(PCHAR)(address) - \
(ULONG_PTR)(&((type *)0)->field)))
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
...
GN>Но сейчас есть острая необходимость в прикладном софте под ядро, например антивирус, что бы уметь действително что-то находить, должен работать напрямую с диском, а сейчас месяцами правятся ошибки 2го порядка из-за треша поинтеров в кривых хуках. И еще надо 2е ядро, что бы это не тормозило работу ОС. А как по-другому то получится, если надо одновременно помнить про 68 ресурсов? Если надо не С с классами, а C++ (те же функторы дают выигрыш в скорости ) — пиши километры кода. boost::? Ну да, не забудем реализовать operator new Так что если какая-то "мелочь" поможет упростить разработку, то это по моему очень хорошо А открытый мютекс можно и в интерфейсе задокументировать, это ерунда после регулярного использования: GN>
GN>//
GN>// Calculate the address of the base of the structure given its type, and an
GN>// address of a field within the structure.
GN>//
GN>#define CONTAINING_RECORD(address, type, field) ((type *)( \
GN> (PCHAR)(address) - \
GN> (ULONG_PTR)(&((type *)0)->field)))
GN>
AS>>>>Ну а куда деваться... Есть множество библиотек, где гварды реализованы именно как некопируемые объекты. Приходится извращаться AS>>>>В этом плане, конечно, решение remark'а интересно тем, что позволяет делать inplace вызовы без каких-либо нарушений. Но вот если хочется блокирования на более долгий период и при этом сам блокируемый объект не важен (т.е. он используется неявно другими объектами, как, например, OLEDB сессия и команды), тогда без RVO, похоже, не обойтись. С соответствующими последствиями.
R>>>В такой ситуации вообще нет проблемы:
AS>>Как раз проблема есть. Придется писать lock для каждого объекта, что как минимум не комильфо. Решение с RVO позволяет просто пользоваться общей базой и держать возврашаемый объект лока (который уже производного типа) константной ссылкой.
R>lock зависит только от базового класса synchronized, но не от конкретного пользовательского класса. Т.ч. всё должно быть ОК.
Объекты _уже_ есть, т.е. отращивать их ниоткуда нельзя. Есть locableValue, которое суть хранит референсы на объект и объект синхронизации. Это дело возвращается пользователю. А что дальше с ним делать — ну вот, собственно, и челендж. Если использовать для гварда RVO, тогда отрастив обертку _гварда_ (а не объект) от общего пустого класса мы получаем бесплатный способ блокировки без указания типа. Пример я уже приводил.
Здравствуйте, alsemm, Вы писали:
A>Здравствуйте, remark, Вы писали:
R>>>>Не могу сказать за ядро Windows, но в Linux вот: A>>>... A>>>Дык это все случае, кода надо ходить по списку вообще без блокировки или без блокировки проверить пусто/не пусто и только потом блокировать?
R>>Когда ходить по списку вообще без блокировки. В Microsoft тоже так хотят — но всё запатентовано, поэтому приходится довольствоваться только проверкой на пустоту
A>Вот не думал, что в GPL-ом ядре есть патентованный код. Что за патенты? где про это можно почитать? Было бы очень интересно.
Скажу про то, что заню. RCU (использование которого в ядре linux я приводил здесь
) запатентовано и перепатеновано слева-напрво и справа-налево. Основной автор — Paul McKenney, основной правопреемник — International Business Machines Corporation (IBM). IBM использует эту технологию в своих коммерческих серверах, а ядро линукса, как я понимаю, используется как "песочница". IBM выдаёт на все эти патенты специальное разрешение, которое разрешает использовать их в ядре линукс.
Т.е. не смотря на то, что код покрыт GPL, используемые алгоритмы защищены патентами Соединенных Штатов, что будет посерьёзнее GPL.
Где про это почитать? Не знаю. Мне кажется — нигде. Это не афишируется.
Здесь смотри список патентов (поиск по: автор — McKenney, правопреемник — International Business Machines Corporation): здесь
Так же смотри открытые заявки на патент (поиск по: автор — McKenney, правопреемник — International Business Machines Corporation): здесь
Здравствуйте, alsemm, Вы писали:
R>>Одним словом, "извращённые" методы синхронизации рулят A>Вот не думал, что в GPL-ом ядре есть патентованный код. Что за патенты? где про это можно почитать? Было бы очень интересно.
В твоих программах он тоже, скорее всего, есть...
Здравствуйте, remark, Вы писали:
R>Т.е. не смотря на то, что код покрыт GPL, используемые алгоритмы защищены патентами Соединенных Штатов
Позволяет ли это использовать алгоритмы, защищенные патентами (да поразит аллах того, кто их придумал), в производных от Линукса продуктах? GPLv3 точно позволяет, там о патентах (да поразит аллах того, кто их придумал) сказано четко, но Linux распространяется на условиях GPLv2.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, alsemm, Вы писали:
R>>>Одним словом, "извращённые" методы синхронизации рулят A>>Вот не думал, что в GPL-ом ядре есть патентованный код. Что за патенты? где про это можно почитать? Было бы очень интересно. C>В твоих программах он тоже, скорее всего, есть...
Чужие исходники в свои пректы включаю внимательно прочитав лицензию и для верности спрашиваю у автора, если удается найти его координаты конечно, можно-ли его поделку использовать. Это конечно не 100% гарантия, что все чисто, но хоть что-то.
Здравствуйте, remark, Вы писали:
R>Т.е. не смотря на то, что код покрыт GPL, используемые алгоритмы защищены патентами Соединенных Штатов, что будет посерьёзнее GPL.
Типа берёшь GPL продукт, развиваешь, а что там наразвивал -- патентуешь и оба на!!!
Код хоть и открытый вроде, а переиспользовать всё равно нельзя...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Т.е. не смотря на то, что код покрыт GPL, используемые алгоритмы защищены патентами Соединенных Штатов, что будет посерьёзнее GPL.
E>Типа берёшь GPL продукт, развиваешь, а что там наразвивал -- патентуешь и оба на!!! E>Код хоть и открытый вроде, а переиспользовать всё равно нельзя...
Дети идут спать!
Лицензия на исходный код и патент — это совершенно разные вещи. Лицензия защищает исходный код, патент — изобретение.
Дети не могут запатентовать просто исходный код. Дети могут запатентовать только новые, нетривиальные и полезные алгоритмы.
Плюс к этому, если дети запатентуют како-либо алгоритм на территории России, то большинство людей в мире просто глубоко положет на это.
Здравствуйте, remark, Вы писали:
R>Плюс к этому, если дети запатентуют како-либо алгоритм на территории России, то большинство людей в мире просто глубоко положет на это.
Ну так и что? Патентуешь (в США) идеи и алгоритмы, а кто переиспользует код, на этих алгоритмах базирующийся -- тот нарушит твой патент и будет ему а-та-та от слепой амерской Фемиды. А то что он остался, в соответсвии с лицензией GPL пофиг
p. s.
А разве в РФ алгоритмы можно патентовать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
R>>Т.е. не смотря на то, что код покрыт GPL, используемые алгоритмы защищены патентами Соединенных Штатов, что будет посерьёзнее GPL.
E>Типа берёшь GPL продукт, развиваешь, а что там наразвивал -- патентуешь и оба на!!! E>Код хоть и открытый вроде, а переиспользовать всё равно нельзя...
Нет, конечно. Пункт 7 в GPLv2:
If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
) — пиши километры кода. boost::? Ну да, не забудем реализовать operator new 
Так что если какая-то "мелочь" поможет упростить разработку, то это по моему очень хорошо 
