c++ - memory mapped files and pointers to volatile objects -


my understanding of semantics of volatile in c , c++ turns memory access (observable) side effects. whenever reading or writing memory mapped file (or shared memory) expect the pointer volatile qualified, indicate in fact i/o. (john regehr wrote article on semantics of volatile).

furthermore, expect using functions memcpy() access shared memory incorrect, since signature suggests volatile qualification cast away, , memory access not treated i/o.

in mind, argument in favor of std::copy(), volatile qualifier won't cast away, , memory accesses being correctly treated i/o.

however, experience of using pointers volatile objects , std::copy() access memory mapped files it's orders of magnitude slower using memcpy(). tempted conclude perhaps clang , gcc overly conservative in treatment of volatile. case?

what guidance there accessing shared memory regards volatile, if want follow letter of standard , have semantics rely on?


relevant quote standard [intro.execution] §14:

reading object designated volatile glvalue, modifying object, calling library i/o function, or calling function of operations side effects, changes in state of execution environment. evaluation of expression (or subexpression) in general includes both value computations (including determining identity of object glvalue evaluation , fetching value assigned object prvalue evaluation) , initiation of side effects. when call library i/o function returns or access through volatile glvalue evaluated side effect considered complete, though external actions implied call (such i/o itself) or volatile access may not have completed yet.

my understanding of semantics of volatile in c , c++ turns memory access i/o

no not that. volatile communicate programmer compiler memory area can changed @ time, "something else".

"something else" might lot of different things. examples:

  • memory-mapped hardware register
  • variable shared isr
  • variable updated callback function
  • variable shared thread or process
  • memory area updated through dma

since standard (5.1.2.3) guarantees access (read/write) volatile object may not optimized away, volatile can used block compiler optimizations, useful in hardware-related programming.

whenever reading or writing memory mapped file (or shared memory) expect the pointer volatile qualified

not necessarily, no. nature of data doesn't matter, how updated.

i expect using functions memcpy() access shared memory incorrect

overall depends on definition of "shared memory". problem whole question, because keep talking "shared memory" not formal, well-defined term. memory shared isr/thread/process?

yes, memory shared isr/thread/process might have declared volatile, depending on compiler. only becaue volatile can prevent compiler making incorrect assumptions , optimize code accessing such "shared" variables wrong way. prone happen on older embedded systems compilers. shouldn't necessary on modern hosted system compilers.

volatile not lead memory barrier behavior. not (necessarily) force expressions executed in order.

volatile not guarantee form of atomicity. why _atomic type qualifier added c language.

so copy issue - if memory area "shared" between several isrs/threads/processes, volatile won't @ all. instead need means of synchronization, such mutex, semaphore or critical section.

in mind, argument in favor of std::copy(), volatile qualifier won't cast away, , memory accesses being correctly treated i/o.

no, wrong, mentioned reasons.

what guidance there accessing shared memory regards volatile, if want follow letter of standard , have semantics rely on?

use system-specific api:s protect memory access, through mutex/semaphore/critical section.


Comments

Popular posts from this blog

Is there a better way to structure post methods in Class Based Views -

performance - Why is XCHG reg, reg a 3 micro-op instruction on modern Intel architectures? -

jquery - Responsive Navbar with Sub Navbar -