Точки последовательности предотвращают переупорядочение кода через критические границы раздела?

No, sequence points do not prevent rearranging of operations. The main, most broad rule that governs optimizations is the requirement imposed on so called observable behavior. Observable behavior, by definition, is read/write accesses to volatile variables and calls to library I/O functions. These events must occur in the same order and produce the same results as they would in the "canonically" executed program. Everything else can be rearranged and optimized absolutely freely by the compiler, in any way it sees fit, completely ignoring any orderings imposed by sequence points.

Of course, most compilers are trying not to do any excessively wild rearrangements. However, the issue you are mentioning has become a real practical issue with modern compilers in recent years. Many implementations offer additional implementation-specific mechanisms that allow user to ask the compiler not to cross certain boundaries when doing optimizing rearrangements.

Since, as you are saying, the protected data is not declared as volatile, formally speaking the access can be moved outside of the protected region. If you declare the data as volatile, it should prevent this from happening (assuming that mutex access is also volatile).

см. Кое-что в [linux-kernel] /Documentation/memory-barriers.txt

Точки последовательности C / C ++ встречаются, например, когда ';' встречается. В этот момент должны возникнуть все побочные эффекты всех операций, которые ему предшествовали. Однако я совершенно уверен, что под «побочным эффектом» подразумеваются операции, которые являются частью самого языка (например, z увеличивается в 'z ++'), а не эффекты на более низких / более высоких уровнях (например, что на самом деле делает ОС что касается управления памятью, управления потоками и т. д. после завершения операции)

Это вроде как ответ на ваш вопрос? Я действительно хочу сказать, что AFAIK концепция точек последовательности на самом деле не имеет ничего общего с побочными эффектами, о которых вы говорите.

hth

Давайте посмотрим на следующий пример:

my_pthread_mutex_lock( &m ) ;
someNonVolatileGlobalVar++ ;
my_pthread_mutex_unlock( &m ) ;

Функция my_pthread_mutex_lock () просто вызывает pthread_mutex_lock (). Используя my_pthread_mutex_lock (), я уверен, что компилятор не знает, что это функция синхронизации. Для компилятора это просто функция, и для меня это функция синхронизации, которую я могу легко переоснять. Потому что соменонволатилеглобальвар - глобальный, я ожидал, что компилятор не двигает соменонволатилеглобальвар ++ за пределами критического раздела. Фактически, благодаря наблюдаемым поведению , даже в ситуации с одной резьбой, компилятор не знает, если функция до того, и то, как после этой инструкции изменяют глобальные VAR. Итак, чтобы сохранить наблюдаемое поведение правильным, он должен держать заказ выполнения, как написано. Я надеюсь, что Pthread_mutex_lock () и pthread_mutex_unlock () также выполняют Барьеры памяти .

Я прав?

Если я пишу:

my_pthread_mutex_lock( &m ) ;
someNonVolatileGlobalVar1++ ;
someNonVolatileGlobalVar2++ ;
my_pthread_mutex_unlock( &m ) ;

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

Теперь, если я пишу:

someGlobalPointer = &someNonVolatileLocalVar;
my_pthread_mutex_lock( &m ) ;
someNonVolatileLocalVar++ ;
my_pthread_mutex_unlock( &m ) ;

или

someLocalPointer = &someNonVolatileGlobalVar;
my_pthread_mutex_lock( &m ) ;
(*someLocalPointer)++ ;
my_pthread_mutex_unlock( &m ) ;

- это компилятор, делающий то, что ожидает, что неподвижный разработчик?