Индусские программисты и индусский код

[Alexandr]

найти пример мульти-процессора с sequential consistency я не смог хотя в теории они должны существовать, но по поводу джавы вот тут хорошо излагают
http://bartoszmilewski.com/2008/11/11/w ... nsistency/

это как операционка с микроядром, в теории существует, да и на практике, но только в учебных целях, так как коммерчески бессмысленна (хотя она и в теории бессмысленна, никто не знает, как она будет перезапускать, например, менеджер памяти, если он свалится)
sequntial order processors есть - это все интелловское добро до Pentium Pro (не знаю насколько к нему подходит определение мультипроцессор)

[Alexandr]

потому что они происходят в кеше проца, регистре и т.д. А если поставить volatile и все изменения сразу записываются в основную память, то второй поток все увидит.

volatile никак не поможет скинуть процессорный кэш в основную память или там записать туда минуя процессорный кэш

Не может, но в джаве оно определяет happens before relation, т.е. гарантируется что присвоение X = 1 увидит второй поток прежде чем первый начнет выполнять if(Y == 1), и тогда два нолика никогда не случатся.
Как это делается на разном железе я ХЗ, я не железячник.

я там выше написал:
write barrier - это сброс store buffer в кеш, до того как другие операции записи будут обработаны
read barrier - это обработка invalidation queue на кеше до чтения кеш-линии
full memory barrier - это и то и другое

на некоторых платформах (в голову сразу приходит Alpha, хотя на 100% я не уверен) memory barrier - это ordering instruction внутри самого pipeline, до того как оно даже до блоков исполнения дойдет (возможно на этапе выделение ресурсов под микрооперацию)

все что делает volatile - это гарантирует, что операции чтения и записи не будут перемешаны или убраны оптимизатором при jit-компиляции и что верные для исполняемой платформы memory fences будут сгенерированы (в отличии от С++ pre C++11)

если вот это утверждение верно (позже еще сам гляну, интересно стало, раньше не знал)

Присваивание double и long с volatile модификатором - атомарное.

то volatile, например, может использовать на x86 инструкции атомарного чтения\записи вида CMPXCHG8B, на x64 само собой должно работать (хотя наверняка я не знаю)

[crypto5]

потому что они происходят в кеше проца, регистре и т.д. А если поставить volatile и все изменения сразу записываются в основную память, то второй поток все увидит.

volatile никак не поможет скинуть процессорный кэш в основную память или там записать туда минуя процессорный кэш

Не может, но в джаве оно определяет happens before relation, т.е. гарантируется что присвоение X = 1 увидит второй поток прежде чем первый начнет выполнять if(Y == 1), и тогда два нолика никогда не случатся.
Как это делается на разном железе я ХЗ, я не железячник.

я там выше написал:
write barrier - это сброс store buffer в кеш, до того как другие операции записи будут обработаны
read barrier - это обработка invalidation queue на кеше до чтения кеш-линии
full memory barrier - это и то и другое

на некоторых платформах (в голову сразу приходит Alpha, хотя на 100% я не уверен) memory barrier - это ordering instruction внутри самого pipeline, до того как оно даже до блоков исполнения дойдет (возможно на этапе выделение ресурсов под микрооперацию)

все что делает volatile - это гарантирует, что операции чтения и записи не будут перемешаны или убраны оптимизатором при jit-компиляции и что верные для исполняемой платформы memory fences будут сгенерированы (в отличии от С++ pre C++11)

если вот это утверждение верно (позже еще сам гляну, интересно стало, раньше не знал)

Присваивание double и long с volatile модификатором - атомарное.

то volatile, например, может использовать на x86 инструкции атомарного чтения\записи вида CMPXCHG8B, на x64 само собой должно работать (хотя наверняка я не знаю)

Да, это написано в статье выше.

[Интеррапт]

все что делает volatile - это гарантирует, что операции чтения и записи не будут перемешаны или убраны оптимизатором при jit-компиляции и что верные для исполняемой платформы memory fences будут сгенерированы (в отличии от С++ pre C++11)

если вот это утверждение верно (позже еще сам гляну, интересно стало, раньше не знал)

Присваивание double и long с volatile модификатором - атомарное.

Конечно верно, не сам же я это придумал.

то volatile, например, может использовать на x86 инструкции атомарного чтения\записи вида CMPXCHG8B, на x64 само собой должно работать (хотя наверняка я не знаю)

В зависимости от архитектуры - оно может использовать что угодно, вплоть даже до блока синхронизации. Начиная с 1.5 volatile вообще нужно осторожно использовать, т.к. доступ к нему может быть и в 10 раз медленней. В большинстве случаев AtomicXxxxx классы дадут лучший performance.

[Alexandr]

Конечно верно, не сам же я это придумал.

ну я просто не знал

В зависимости от архитектуры - оно может использовать что угодно, вплоть даже до блока синхронизации. Начиная с 1.5 volatile вообще нужно осторожно использовать, т.к. доступ к нему может быть и в 10 раз медленней. В большинстве случаев AtomicXxxxx классы дадут лучший performance.

этого тоже не знал

все никак не доберусь до книженции Java Performance Tuning

[Интеррапт]

все никак не доберусь до книженции Java Performance Tuning

Java Performance Tuning - она древняя как моя жизнь (начала 2000-х) и чтиво так-себе. А если ты про Java Performance (которая 2011-го года)
http://www.amazon.com/Java-Performance- ... erformance

то постучав ко мне в личку - можно найти PDF файл

[Alexandr]

то постучав ко мне в личку - можно найти PDF файл

это прекрасно

[crypto5]

все никак не доберусь до книженции Java Performance Tuning

Java Performance Tuning - она древняя как моя жизнь (начала 2000-х) и чтиво так-себе. А если ты про Java Performance (которая 2011-го года)
http://www.amazon.com/Java-Performance- ... erformance

то постучав ко мне в личку - можно найти PDF файл

У меня на работе у всех и каждого на полке стоит Java Concurrency in Practice

[Интеррапт]

У меня на работе у всех и каждого на полке стоит Java Concurrency in Practice

Ну это вообще не обсуждается - эта книжка просто обязательна для любого Джава девелопера.

[crypto5]

У меня на работе у всех и каждого на полке стоит Java Concurrency in Practice

Ну это вообще не обсуждается - эта книжка просто обязательна для любого Джава девелопера.

Я ее не читал вообще но на полке стоит

[Интеррапт]

Черпаешь информацию удаленно?

[crypto5]

Черпаешь информацию удаленно?

Та нет, лично наступаю на все грабли

[dotcom]

Это правильный подход. Книжки - зло!

[Alexandr]

Черпаешь информацию удаленно?

Та нет, лично наступаю на все грабли

не знаю как у вас, но у меня бы лоб заболел от такого
имхо, все же лучше не наступать на самые популярные, на которые до тебя уже многие наступали

[Flash-04]

есть два типа людей: первые учаться на своих ошибках, вторые - на чужих (с)

[fruit6]

есть два типа людей: первые учаться на своих ошибках, вторые - на чужих (с) 8)

это миф. есть два типа людей: которые учатся на своих ошибках и те, кто ни на чем не учится

[Flash-04]

я бы сказал что это скорее обобщение

[crypto5]

Черпаешь информацию удаленно?

Та нет, лично наступаю на все грабли

не знаю как у вас, но у меня бы лоб заболел от такого
имхо, все же лучше не наступать на самые популярные, на которые до тебя уже многие наступали

На самом деле здесь два аспекта моей философии:
1. Я стараюсь минимизировать набор инструментов которым пользуюсь, т.е. в плане конкурентного программирования нужно не так уж и много примитивов что бы писать нормальные программы. Джава и та книжка ими перегружена.
2. Я книжки по программированию действительно не люблю читать, слишком много воды, и не по делу. Читаю статей много, особенно когда нужно разобраться с каким то вопросом. А в книжках вроде указанных, мне прийдется влить в мозг море информации которая никогда не пригодится.

[АццкоМото]

ути-ути

Variables shared between multiple threads (e.g., instance variables of objects) have atomic assignment guaranteed by the Java language specification for all data types except longs and doubles.

Да, был неправ

[Alexandr]

отчасти соглашусь, отчасти нет

1. Я стараюсь минимизировать набор инструментов которым пользуюсь, т.е. в плане конкурентного программирования нужно не так уж и много примитивов что бы писать нормальные программы. Джава и та книжка ими перегружена.

У меня как раз стратегия совсем наоборот, я стараюсь знать как можно больше, стараясь соблюдать life-work balance, а применять лучшее из того, что знаю. Исток этого состоит в том, что чем глубже и больше знаешь, тем более качественные решения получаются (и тем меньше времени думаешь над ними), потому что выбора дофига.

2. Я книжки по программированию действительно не люблю читать, слишком много воды, и не по делу. Читаю статей много, особенно когда нужно разобраться с каким то вопросом. А в книжках вроде указанных, мне прийдется влить в мозг море информации которая никогда не пригодится.

К сожалению книг сейчас великое множество, и выбрать те, которые действительно стоит читать не легко. Но это не значит, что читать не нужно. Взял, начал читать, понял, что полная ерунда - бросил на половине, делов то.
Насчет никогда не пригодится - не соглашусь

Будете смеяться, но, я очень часто ориентируюсь на объем книги; как показывает практика, чем меньше объем тем она менее полезна. Например, по .NET я вообще книги не читаю, которые меньше 1000 страниц. (Это касается и многих других тем).
Ну вот, например, что можно такого написать в книге "Системное программирование под Linux" на 350 страниц , когда Linux Programming Interface - 1500

[valchkou]

а бывает что чтение книг может навредить.
Прочитал я как то в книге Thinking Java by Bruce Eckel's,
когда использовать ArrayList, а когда LinkedList, запомнил.
Но затем стал к собеседованию готовиться и дай думаю тест проведу, чтобы с цифрами.
И оказалось, то Брюс полную фигню написал. А если бы я в продакш пошел. А кто то ведь повелся.
Да книжки читать надо, но и грабли пощупать не лишним будет,
а теперь если книжки и читаю по яве, то строго по советам Интеррапта

[Alexandr]

Ну почему же, это был ваш бесценный опыт
остальное то правдой было или еще местами приврал?

[valchkou]

Ну почему же, это был ваш бесценный опыт
остальное то правдой было или еще местами приврал?

Он не приврал, а написал теоретические выводы без практического подтверждения, и без понимания, как это работатет на самом деле.
Из серии 300 вопросов для интервью.
А после того как я увидел одноименые книжки от него же по С++ и тд, то я вообще потерял к автору доверие.

[Alexandr]

Ну почему же, это был ваш бесценный опыт
остальное то правдой было или еще местами приврал?

Он не приврал, а написал теоретические выводы без практического подтверждения, и без понимания, как это работатет на самом деле.
Из серии 300 вопросов для интервью.
А после того как я увидел одноименые книжки от него же по С++ и тд, то я вообще потерял к автору доверие.

ну там и книжка такая: пришел, услышал, прошел интервью, забыл

[Мальчик-Одуванчик]

Ну почему же, это был ваш бесценный опыт
остальное то правдой было или еще местами приврал?

Он не приврал, а написал теоретические выводы без практического подтверждения, и без понимания, как это работатет на самом деле.
Из серии 300 вопросов для интервью.
А после того как я увидел одноименые книжки от него же по С++ и тд, то я вообще потерял к автору доверие.

ну там и книжка такая: пришел, услышал, прошел интервью, забыл

Одна из наиболее бестолковых монографий по C++, сравнимая разве что с опусами Дейтела или Праты.