-
- Вы привели только два оператора. А что происходит дальше? Сдается мне, что компилятор сделал все правильно. Или нет? - Bill(22.01.2014 13:20)
- дальше возврат из функции - могу привести больше кода, но смысл? - я хотел показать, что компилятор может переставить операции даже с volatile переменными: видно, что первый оператор glob_wbuf[glob_ww]=in_buf[i]; транслируется в ldub ... stb ... а ыыыыыыыыыы(147 знак., 22.01.2014 15:46, )
- так все таки можете проверить предложенный мной вариант и показать полное объявление переменных и массива (во всех местах где они объявляются, если юзаются в разных файлах)? - aoreh(22.01.2014 15:56)
- Уточняющие вопросы. glob_wbuf - volatile? in_buf - volatile? - SciFi(22.01.2014 15:49)
- нет. сейчас я посмотрю еще варианты С - напишу результаты. самому интересно. - ыыыыыыыыыы(22.01.2014 15:57, )
- Ну тогда компилятор всё правильно сделал. Другими словами, сам дурак. - SciFi(22.01.2014 16:04)
- возможно меня извинит, то что это чужой код и вроде как сказали, что volatile пробовали к массиву - не помогло. ну и volatile еще тратит время (ld/st) на работу с ним... то есть решение с барьером, имхо, лучше, но про порядок таких операций я бы ыыыыыыыыыы(116 знак., 22.01.2014 16:32, )
- Стандарт - по ссылке -> SciFi(225 знак., 22.01.2014 16:37, ссылка)
- спасибо - ыыыыыыыыыы(22.01.2014 16:42, )
- Стандарт - по ссылке -> SciFi(225 знак., 22.01.2014 16:37, ссылка)
- при объявлении приемника volatile - порядок получается правильный. но я не уверен, что это лучше барьера. по хорошему, в TSO в барьере должно еще flush быть - ыыыыыыыыыы(22.01.2014 16:14, )
- возможно меня извинит, то что это чужой код и вроде как сказали, что volatile пробовали к массиву - не помогло. ну и volatile еще тратит время (ld/st) на работу с ним... то есть решение с барьером, имхо, лучше, но про порядок таких операций я бы ыыыыыыыыыы(116 знак., 22.01.2014 16:32, )
- Ну тогда компилятор всё правильно сделал. Другими словами, сам дурак. - SciFi(22.01.2014 16:04)
- нет. сейчас я посмотрю еще варианты С - напишу результаты. самому интересно. - ыыыыыыыыыы(22.01.2014 15:57, )
- дальше возврат из функции - могу привести больше кода, но смысл? - я хотел показать, что компилятор может переставить операции даже с volatile переменными: видно, что первый оператор glob_wbuf[glob_ww]=in_buf[i]; транслируется в ldub ... stb ... а ыыыыыыыыыы(147 знак., 22.01.2014 15:46, )
- Не понял проблемы. Этот код всегда будет потоконебезопасным. Даже в варианте с барьером. Барьер лишь снижает вероятность неблагополучного события - Sergey_N(22.01.2014 11:31, )
- при переключении потока регистры сохраняются и т.п. код с барьером стал безопасным (ошибка пропала) - ну это циклический буффер - тут положили - там забрали. признаком положили/забрали является указатель, при правильной последовательности никаних ыыыыыыыыыы(206 знак., 22.01.2014 15:34, )
- Этот код будет безопасным только, если glob_ww не меняется ни в прерывании, ни в другом потоке. Иначе даже барьер не гарантирует, что эта переменная будет иметь правильное значение. - Sergey_N(22.01.2014 16:40)
- меняется в одном потоке. в другом потоке другой указатель, а этот только читается. вроде как стандартная конструкция, со времен Дейкстры еще... - ыыыыыыыыыы(22.01.2014 16:51, )
- Ну и зачем вам тогда барьер? ИМХО, тут в алгоритме какая-то проблема, а не в компиляторе. - Sergey_N(22.01.2014 16:54)
- меняется в одном потоке. в другом потоке другой указатель, а этот только читается. вроде как стандартная конструкция, со времен Дейкстры еще... - ыыыыыыыыыы(22.01.2014 16:51, )
- Этот код будет безопасным только, если glob_ww не меняется ни в прерывании, ни в другом потоке. Иначе даже барьер не гарантирует, что эта переменная будет иметь правильное значение. - Sergey_N(22.01.2014 16:40)
- +1 нефиг полагаться на атомарность операций (с неизвестным порядком исполнения). - fk0(22.01.2014 11:56)
- при переключении потока регистры сохраняются и т.п. код с барьером стал безопасным (ошибка пропала) - ну это циклический буффер - тут положили - там забрали. признаком положили/забрали является указатель, при правильной последовательности никаних ыыыыыыыыыы(206 знак., 22.01.2014 15:34, )
- Любопытно, а если эту конструкцию изменить на: aoreh(62 знак., 22.01.2014 00:31)
- тоже любопытно. во что разворачивает glob_wbuf[glob_ww++]=in_buf[i]; - Vit(22.01.2014 00:52)
- удивительно, но такая конструкция правильно, даже если glob_wbuf не volatile - ыыыыыыыыыы(22.01.2014 16:25, )
- классика - Vit(22.01.2014 16:44)
- удивительно, но такая конструкция правильно, даже если glob_wbuf не volatile - ыыыыыыыыыы(22.01.2014 16:25, )
- тоже любопытно. во что разворачивает glob_wbuf[glob_ww++]=in_buf[i]; - Vit(22.01.2014 00:52)
- di(); glob_ww++; ei(); -- не вариант? Разумеется di() и ei() являются барьерами одновременно (ибо на 16-битной платформе 32-битный счётчик один фиг за две операции). Ну не совсем ei() прямо таки, а begin_critical() с запоминанием и end_critical() fk0(171 знак., 21.01.2014 23:41)
- Типа баг компилятора? Ну и как от багов компилятора спасут "средства RTOS"? Тогда уж сразу на асме кодить, хотя и у ассемблера могут быть баги :-) - SciFi(21.01.2014 19:35)
- почему баг - имеет право. для арма думаю также будет при О2 и выше. просто средства языка С не позволяют запретить оптимизацию. ну а в средствах RTOS такое либо на асме напишут, либо через критическую секцию (что не гуд) - ыыыыыыы(22.01.2014 00:23, )
- volatile как раз и говорит компилятору не оптимизировать доступ к переменной. так что или она таки объявлена неправильно или компайлер по какой-то причине не воспринимает ее как volatile или таки баг оптимизатора - aoreh(22.01.2014 01:18)
- Есть такая штука, как "sequence point". Имеет непосредственное отношение к "volatile". Слыхали о таком? - SciFi(22.01.2014 00:37)
- типа, это: ; это sequence point по-моему современным компилерам на это плевать. то есть побочного эфекта переставление записей не имеет пока мы в рамках однопотоковой системы.... но вот изменение поведения при volatile glob_buf как то шатает мою ыыыыыыыыыы(15 знак., 22.01.2014 16:41, )
- нет, может заменить barrier или теоретическое определение? из теории про это я знаю memory ordering - TSO PSO Strong - ыыыыыыыыыы(22.01.2014 15:53, )
- почему баг - имеет право. для арма думаю также будет при О2 и выше. просто средства языка С не позволяют запретить оптимизацию. ну а в средствах RTOS такое либо на асме напишут, либо через критическую секцию (что не гуд) - ыыыыыыы(22.01.2014 00:23, )
- Вы привели только два оператора. А что происходит дальше? Сдается мне, что компилятор сделал все правильно. Или нет? - Bill(22.01.2014 13:20)