Релиз Go 1.1

Это те самые, что сделали Plan 9.

Тому поведению я вижу два объяснения:

1. Работа с объектом g в основном происходит во время присваивания g=t в setup, при этом g!=nil, но и g!=t, т.е. g не указывает на объект, а имеет невалидное значение. В этом случае возникает вопрос чем Go лучше C для прогрмаммирования многопоточных приложений?
2. Присваивание g=t завершилось и, следовательно не только g!=nil, но и g==t. Тогда g.msg может быть неинициализированно только в том случае, когда присваивание g=t выполнилось до t.msg = «hello, world», т.е. был изменен порядок выполнения

Что я пропустил?

-- Указатели - это только часть проблем Си. Это не проблема C, а твоя половая проблема, обезьяна.

рада сообщить о выходе...

Ура! Радостное ненужно!

проектированием занимались Роб Пайк и Кен Томпсон...

Я думал, они уж померли давно! Это же «те самые», что юникс смастырили, да?

Ты говорящаяя обезьяна ?

Тому поведению я вижу два объяснения:

первое правильное, а чем лучше C - не скажу, у них разные подходы, это уже на вкус и цвет

В чём смысл юзать официальный компилятор Go, когда gccgo имеет ряд плюсов в т.ч. и оптимизацию?

В чём смысл юзать официальный компилятор Go, когда gccgo имеет ряд плюсов

у меня gccgo не всё собирает. Там какие-то ошибки при линковке выползают, которых если компилять гуглёвым компилём то таких ошибок нет. (возможно из-за cgo или ещё что-то)

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

Если бы все было так просто... Тут во-первых непонятно когда сбрасывать кеш (не факт, что это будет выполняться после завершения всей команды, а не после завершения какой-то из стадий ее выполнения), во-вторых переменная может разместится на 2 страницы кеша.

На x86 вообще есть операции с гарантией атомарности, но зачастую это достаточно экзотические операции и естественно медленные. Дешевле отдать проблему синхронизации в многопоточной программе программисту, котрый наделает мьютексов и решит все потенциальные проблемы замедлением в нескольких местах (какой я оптимист прям ^_^), чем замедлять каждую(!) инструкцию.

В этом случае возникает вопрос: чем Go лучше C для программирования многопоточных приложений?

тем, что можно не загружать моск вот такими вещами, а использовать каналы.

Версия gcc какая? У меня были ошибки при сборке программ, когда стояла не последняя версия, там между 4.6 и 4.7 в go изменения незначительные в именах подключаемых модулей были.

У gccgo был косяк с относительными путями. Багтрекер говорит что в 1.1 должны были пофиксить.

Не знаю про первое, а в документации дается второе объяснение.

ссылка?

http://go.googlecode.com/hg/doc/go_mem.html

Что я пропустил?

http://ideone.com/bsN2DI

http://ideone.com/T0WBQL

http://ideone.com/eYjN1M

точно, они наркоманы :), ну что ж - сегодня я узнал о Go чуть больше, может когда-нибудь пригодится

кроме хипсторов?

The Python Paradox.

В него даже libc влинкована статически? Закопайте это немедленно.

Это не баг, это фича. Задеплоить бинарь можно куда-угодно просто скопировав, если совпадают архитектура процессора и ОС.

Эх, когда там уже нормальные генерики появятся? 2013 год на дворе.

Как только будет решена Главная Проблема генериков: http://research.swtch.com/generic

http://go.googlecode.com/hg/doc/go_mem.html

Если то что написано по ссылке правда, то го это просто ужасный язык... Это даже хуже дельфи, в котором нужно ожидать исключение в каждой строчке.

В него даже libc влинкована статически? Закопайте это немедленно.

Бинарная переносимость статически собранной программы лучше. Сам заройся и не высовывайся.

Так ведь в си так же допускается переупорядочивание инструкций (из-за чего, в частности, и придуман volatile)? И вообще C11 местами сильно похож на эту доку.

Если то что написано по ссылке правда, то го это просто ужасный язык

Всего лишь UB, как и в си.

Это объясняется архитектурой современных процессоров.

http://ru.wikipedia.org/wiki/Intel_P6

См. переупорядочивание инструкций.

Так ведь в си так же допускается переупорядочивание инструкций.

Насколько мне помнится volatile имеет отношение скорее к «кешированию» данных (особенно в регистрах процессора). Хотя на переупорядочивание инструкций в теории это тоже может повлиять.

В принципе, когда дело доходит до локальных переменных и оптимизации выполнения проверки условий, то может случится все что угодно. Но вот чтобы менялся линейно заданный порядок модификации глобальных переменных, или порядок вызова функций, такого не припомню (опять же не имею ввиду if( a&&printf(«Hello world!\n»); ).

В го просто совершенно другой подход к конкурентности, отличный от традиционного «общение через разделяемую память».
Вместо этого, го использует подход «разделяй память через общение», и использует для общения каналы.
Вот несколько полезных ссылок:
http://swtch.com/~rsc/thread/
http://swtch.com/~rsc/talks/threads07/
https://www.youtube.com/watch?v=f6kdp27TYZs
https://www.youtube.com/watch?v=hB05UFqOtFA

Компилятор вправе явно переупорядочить инструкции доступа к non-volatile переменной, если это не влияет на поток выполнения.

Так это не от языка зависит, а от процессора, например команды :

mov eax, 5 mov ebx, 10

могут выполняться в обратной последовательности.

Си - фактически однопоточный язык by design. Компилятор гарантирует только то, что в текущем потоке эффект выполнения инструкций си будет таким, как если бы они выполнялись в порядке записи. Другой поток или обработчик сигнала могут увидеть совсем другую картину. volatile дополнительно гарантирует, что любой наблюдатель за пределами текущего потока увидит то же самое, поэтому и кеширование, и переупорядочивание ограничиваются.

Если не ошибаюсь, так же дела обстоят и в яве.

Чем он лучше D? Rust?

модификатор volatile гарантирует только то, что переменная не будет кешироваться в регистре и ничего больше.

Лучшее соотношение фичи/мозготрах.

В си нет таких понятий, как регистр или кеширование.

Когда у знаменитого скульптора спросили как из камня создать шедевр. Он ответил, что нет ничего проще, надо только убрать все лишнее.

Rust и D - нагромождение концепций, а в Go нет ничего лишнего.

в России живем же, только коммерция, только хардкор

тем, что он «реально» используется в индустрии в отличии от перечисленных

Так себе аргумент.

И модификатора «register» тоже нет ??

Не совсем понимаю логику. Как же тогда блокировки работают?

m.lock();
a=0;
b=1;
m.unlock();

Почему можно переупорядочить a=0; и b=1; но при этом нельзя переупорядочить a=0; и m.lock();

У компилятора есть информация из объявления (т.к. про реализацию lock() он может ничего не знать на этапе компиляции одного из кусков программы), что функция lock у некоторого мьютекса m должна точно выдерживать порядок выполнения?

Алсо, некоторые товарищи любят спинлоки использовать и все работает вроде как...

P.S. В принципе, если a и b будут локальными, то согласен, компилятор может вообще код присваивания a и b удалить, если a и b больше вообще не встречаются. Но локальную переменную не расшаришь-же...

флеш под линукс в итоге благополучно закопали, спрашивается - что это и кому было надо?

Адоба спрашивала: парни, вам нужен флеш под линуксом? ЛОР в едином порыве ответил: да кому это говно нужно?

Адоба помолчала секунду и изрекла: а внотури, кому?

Модификатор имеет другой смысл (по сути, никакого смысла давно уже), а регистры процессора даже не упоминаются в стандарте. Их может и не быть ;)

Объясните мне кто-нибудь, чем круто при объявлении функции или переменной ставить тип после нее, а не до (в стиле Паскаля). Мне это кажется нелогичным и некрасивым.

Я имел в виду только инструкции доступа к данным. Вызовы функций, конечно, переупорядочивать нельзя.

Собственно, иначе гарантировать вообще ничего нельзя было бы.

В отличие от си таким образом получается (в особенности для функций и прочих составных типов), что тип целиком указан после идентификатора и читается справа налево, реже требуя скобки.

Вызовы функций, конечно, переупорядочивать нельзя.

А вызовы никто и не переупорядочивать и не собирался (все варианты не буду приводить).

m.lock();
m.unlock();
a=0;
b=1;

Если a и b локальные, то можно переупорядочивать как угодно. Если они будут глобальными, то этого делать нельзя (во всяком случае я всегда так считал).

Я кажется знаю пример о котором речь. В принципе, тут нет переупорядочивания, но эффект может очень походить на него.

int a, b;

void f()
{
  int c[10];
  for(int i=0; i<10; i++)
    c[i]=a*b+i;
}

Если a и b будет менятся в процессе выполнения функции, то функция скорее всего об этом может не узнать. Т.к. компилятор при включении оптимизации решит, что посчитать заранее a*b и потом его подставлять на каждой итерации цикла явно быстрее. Без volatile он именно так и поступит. С volatile будет честно высчитывать a*b на каждой итерации. Наличие или отсутствие блокировок в теле цикла или вызовов других функций на результат никак не повлияет.

Все таки о переупорядочивании обращения к глобальным переменным хотелось бы нотариально заверенный скриншот или гиперссылку...

Вот тут интересная практика применения Go
http://andrewwdeane.blogspot.ru/2013/05/the-reliability-of-go.html?utm_source...

Предчувствую появление языка Ya!

а в Go нет ничего

Точка.

тем, что он «реально» используется в индустрии

Ты правильно взял слово реально в кавычки.