Comments on: Volatile: C Keyword Myths Dispelled http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html Making Your Code Faster, Stronger, Safer… Thu, 18 Feb 2010 05:11:26 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: mjordan http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-3490 mjordan Thu, 18 Feb 2010 05:11:26 +0000 http://www.safercode.com/blog/?p=33#comment-3490 There is another keyword I can't understand well: restrict for pointers. There is another keyword I can’t understand well: restrict for pointers.

]]> By: RAHUL YADAV http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-3454 RAHUL YADAV Mon, 28 Dec 2009 19:55:50 +0000 http://www.safercode.com/blog/?p=33#comment-3454 volatile is related to optimization which impacts the hardwar related access of variables. WHile multi threading requires exclusive operations (meaning no other thread is alowed to access the critical section). These both may be required at times, but totally un related. Suppose, a program is multithreaded but it uses a variable which stores some hardware address, and 2 threads accesses that variable. Then, too variable can be declared as volatile and can be protected with mutex. volatile is related to optimization which impacts the hardwar related access of variables. WHile multi threading requires exclusive operations (meaning no other thread is alowed to access the critical section). These both may be required at times, but totally un related.
Suppose, a program is multithreaded but it uses a variable which stores some hardware address, and 2 threads accesses that variable. Then, too variable can be declared as volatile and can be protected with mutex.

]]> By: GregK http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-1171 GregK Mon, 20 Apr 2009 15:25:49 +0000 http://www.safercode.com/blog/?p=33#comment-1171 Author completely misunderstood 'volatile' and multithreading. Multithread program completely do not need atomicly access! what for? What if platform do not support atomic access? Atomic access is also not specified in Ansi C 89 (i do not know what about C99). Mutual exclusion is enough to secure multithreading access. Author completely misunderstood ‘volatile’ and multithreading. Multithread program completely do not need atomicly access! what for? What if platform do not support atomic access? Atomic access is also not specified in Ansi C 89 (i do not know what about C99). Mutual exclusion is enough to secure multithreading access.

]]> By: Shantanu Goel http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-322 Shantanu Goel Tue, 10 Mar 2009 17:49:32 +0000 http://www.safercode.com/blog/?p=33#comment-322 Derek, this is interesting. BTW I have used gcc 3.x and gcc 4.2.4 and both give similar results (at O1 as well as O2). Both these versions output different code but do move around the statement that stores 2 to j. I guess that is all the more reason to not use volatiles with this particular "feature" in mind as many compilers haven't got it right ;) Derek, this is interesting. BTW I have used gcc 3.x and gcc 4.2.4 and both give similar results (at O1 as well as O2). Both these versions output different code but do move around the statement that stores 2 to j. I guess that is all the more reason to not use volatiles with this particular “feature” in mind as many compilers haven’t got it right ;)

]]> By: Derek Jones http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-321 Derek Jones Tue, 10 Mar 2009 16:28:40 +0000 http://www.safercode.com/blog/?p=33#comment-321 @Shantanu: A compiler that performs the optimization you give does not conform to the requirements contained in the C Standard. Two sentences does from the previously given quote: http://c0x.coding-guidelines.com/6.7.3.html Sentence 1484 "Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine ..." @Shantanu: A compiler that performs the optimization you give does not conform to the requirements contained in the C Standard.

Two sentences does from the previously given quote:
http://c0x.coding-guidelines.com/6.7.3.html Sentence 1484
“Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine …”

]]> By: Shantanu Goel http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-316 Shantanu Goel Tue, 10 Mar 2009 04:57:34 +0000 http://www.safercode.com/blog/?p=33#comment-316 @Derek: Not necessarily when mixed with non-volatiles. Consider the following example: <code> int main() { int i = 2; volatile int j = 1; while ( i ) { printf("%d\n", i); --i; j = 2; } return 0; }</code> If you were to compile it with optimization on, most compilers will move the "j=2" before the loop. @Derek: Not necessarily when mixed with non-volatiles. Consider the following example:

int main()
{
int i = 2;
volatile int j = 1;
while ( i )
{
printf("%d\n", i);
--i;
j = 2;
}
return 0;
}
If you were to compile it with optimization on, most compilers will move the “j=2″ before the loop.

]]> By: Derek Jones http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-310 Derek Jones Mon, 09 Mar 2009 12:20:56 +0000 http://www.safercode.com/blog/?p=33#comment-310 Declaring objects to be volatile does cause the order of access to be fixed (there may be cases where multiple orders of access are permitted by the language, but that is another issue): "Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3." http://c0x.coding-guidelines.com/6.7.3.html Sentence 1482 It is true that: All shared data in multi-threaded programs must be declared volatile. Atomicity is an unrelated issue and covered by the type sig_atomic_t It seems that developers are not the only people that sometimes have trouble with volatile, compilers often get it wrong as well http://shape-of-code.coding-guidelines.com/2009/03/volatile-handling-sometimes-overly-volatile/ Declaring objects to be volatile does cause the order of access to be fixed (there may be cases where multiple orders of access are permitted by the language, but that is another issue):
“Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3.”

http://c0x.coding-guidelines.com/6.7.3.html Sentence 1482

It is true that: All shared data in multi-threaded programs must be declared volatile. Atomicity is an unrelated issue and covered by the type sig_atomic_t

It seems that developers are not the only people that sometimes have trouble with volatile, compilers often get it wrong as well
http://shape-of-code.coding-guidelines.com/2009/03/volatile-handling-sometimes-overly-volatile/

]]> By: jackjeff http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-204 jackjeff Wed, 25 Feb 2009 10:59:39 +0000 http://www.safercode.com/blog/?p=33#comment-204 @harringf You totally misunderstood my point... :) I totally agree that volatile as multithreaded synchronization is just plainly wrong. It's wrong because automicity is not garanteed and it cannot be used as a synchronization primitive safely. But it's not wrong because of speed. Volatile, despite being totally utterly wrong, is probably faster than most of the synchronization primitives offered by modern operating system. The latter are likely to trigger system calls and/or require memory synchronization instructions. Proper synchronization primitives are expensive. @harringf You totally misunderstood my point… :)

I totally agree that volatile as multithreaded synchronization is just plainly wrong. It’s wrong because automicity is not garanteed and it cannot be used as a synchronization primitive safely. But it’s not wrong because of speed.

Volatile, despite being totally utterly wrong, is probably faster than most of the synchronization primitives offered by modern operating system. The latter are likely to trigger system calls and/or require memory synchronization instructions. Proper synchronization primitives are expensive.

]]> By: Shantanu Goel http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-202 Shantanu Goel Wed, 25 Feb 2009 09:00:36 +0000 http://www.safercode.com/blog/?p=33#comment-202 Jackjeff, yes sync primitives and memory barriers might be slower but the point is that they are anyways needed even if you do use volatile. The point was that if you use these semantics correctly, you don't need volatile at all, using volatile in these cases will not make your program any more safe but just slow it down further. Jackjeff, yes sync primitives and memory barriers might be slower but the point is that they are anyways needed even if you do use volatile. The point was that if you use these semantics correctly, you don’t need volatile at all, using volatile in these cases will not make your program any more safe but just slow it down further.

]]> By: jeffreyb http://www.safercode.com/blog/2009/02/24/volatile-c-keyword-myths-dispelled.html#comment-201 jeffreyb Wed, 25 Feb 2009 07:47:36 +0000 http://www.safercode.com/blog/?p=33#comment-201 @Caleb: I think jackjeff is talking about the actual builtins used to implement synchronization primitives (e.g. compare and swap, etc) which are usually 100-300 times slower than their non-atomic counterparts. @Caleb: I think jackjeff is talking about the actual builtins used to implement synchronization primitives (e.g. compare and swap, etc) which are usually 100-300 times slower than their non-atomic counterparts.

]]>