• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 654 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

atomic intrinsics: shouldn't their parameters be declared volatile?

Jason R Sachs
Expert 1890 points

I just tried to use __addl() on a volatile long, and had to call it like this: "__addl((long *)mypointer)" in order to cast away the volatileness.

Shouldn't the atomic intrinsics be declared with volatile parameters, since they're intended to be atomic operations?

This would apply to __add(), __addl(), __and(), __dec(), __inc(), __or(), __sub(), __subl(), __subr(), __subrl() and __xor().

 

Also, IMHO the bitwise intrinsics __or(), __xor(), and __and() should operate on unsigned int arguments rather than int arguments.

 

  • 0
    TI__Guru**** 249660 points

    Another way to avoid the diagnostic about volatile * long being incompatible with long * is by adding the build options --relaxed_ansi --diag_suppress=169.  

    Jason R Sachs said:
    Shouldn't the atomic intrinsics be declared with volatile parameters

    No.  What atomic means, in this instance, is that the entire operation is carried out in a single instruction.  Once the instruction starts, no other operation (interrupts or whatever) can occur until after the instruction is complete.  These days, it is rather unusual to see an instruction which can read, modify, and write a memory location.

    Volatile isn't about atomic operations.  Rather, it controls whether the compiler is allowed to optimize accesses to a memory location.  Read more about that here.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1890 points

    Georgem said:
    Another way to avoid the diagnostic about volatile * long being incompatible with long * is by adding the build options --relaxed_ansi --diag_suppress=169.

    But I don't want to suppress errors using volatile * long in a function that takes long * as an input, *except* in this one case.

    The difference between

    void foov(volatile long * pl);

    and

    void foo(long *pl);

    is if I have

    long *pa;

    volatile long *pb;

    then I can call foov(pa) and foov(pb), and I can call foo(pa), but I can't call foo(pb) without the compiler complaining that the function signature is incompatible -- and it should complain, because inside the implementation of void foo (long *pl) the compiler can assume that the thing pl is pointing to isn't volatile and can optimize accesses (as you suggested). So calling foo((long *)pb) will keep the compiler from reporting an error, but casting away volatile is a dangerous practice that could be really bad if the implementation of foo() isn't safe for volatile arguments.

    If the implementation of the __add(), _addl(),  __and(), etc. intrinsic functions is that it *is* safe for volatile arguments, then they should really be declared with the volatile qualifier. Otherwise it forces me to use unsafe practices (casting away volatileness) to get code to compile.

  • 0 in reply to Jason R Sachs
    Expert 1890 points

    ...note that the InterlockedIncrement() function under win32 accepts a pointer-to-volatile.

    So do the OSAtomicXxx functions() in Apple OSX.

     

  • 0 in reply to Jason R Sachs
    TI__Guru**** 249660 points

    I point out possible workarounds so you, and others who read these threads, can continue to get work done while improvements are made to the compiler.

    I filed SDSCM00041716 in the SDOWP system to record your request that these intrinsics should accept volatile int * operands without complaint.  Feel free to track it with the SDOWP link in my sig.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1890 points

    Georgem said:
    I point out possible workarounds so you, and others who read these threads, can continue to get work done while improvements are made to the compiler.

    Fair enough.

    I filed SDSCM00041716 in the SDOWP system to record your request that these intrinsics should accept volatile int * operands without complaint.  Feel free to track it with the SDOWP link in my sig.

    Thank you!