Comments on: C/C++: Using Bitfields Effectively http://tdistler.com/2008/07/21/cc-using-bitfields-effectively "To err is human, but to really foul things up you need a computer.” Wed, 30 Nov 2011 07:44:27 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: anduril462 http://tdistler.com/2008/07/21/cc-using-bitfields-effectively/comment-page-1#comment-16148 anduril462 Thu, 08 Sep 2011 17:35:28 +0000 http://tdistler.com/?p=120#comment-16148 Nice article, especially the race condition section. There's one other big problem you missed though. The order of allocation of bit-fields is implementation defined, so it's entirely possible, though unlikely, that the implementation puts the fields in some order other than what you specify. That means, for example, that Base may actually occupy bits 16-31, and your direct read from a hardware register wont work. To use this reliably, you must have a thorough understanding of your implementation (compiler, etc) and even then, it's not likely to be portable. See section 6.7.2.1 of the C99 standard for a list of other implementation-defined and unspecified behaviors to look out for. Nice article, especially the race condition section. There’s one other big problem you missed though. The order of allocation of bit-fields is implementation defined, so it’s entirely possible, though unlikely, that the implementation puts the fields in some order other than what you specify. That means, for example, that Base may actually occupy bits 16-31, and your direct read from a hardware register wont work. To use this reliably, you must have a thorough understanding of your implementation (compiler, etc) and even then, it’s not likely to be portable. See section 6.7.2.1 of the C99 standard for a list of other implementation-defined and unspecified behaviors to look out for.

]]> By: micahc http://tdistler.com/2008/07/21/cc-using-bitfields-effectively/comment-page-1#comment-5183 micahc Sun, 24 Jan 2010 20:28:31 +0000 http://tdistler.com/?p=120#comment-5183 I would say that you should still lock the entire operation, from the caching to the writing back from the cache. If you don't, what happens when you read, release the lock, and then get interrupted by a process that manages to acquire the lock, cache, release the lock, perform the same block processing you were going to do, but with an updated register, reaquire the lock again, and then write. When the first thread runs again it will the clobber the register. I would say that you should still lock the entire operation, from the caching to the writing back from the cache. If you don’t, what happens when you read, release the lock, and then get interrupted by a process that manages to acquire the lock, cache, release the lock, perform the same block processing you were going to do, but with an updated register, reaquire the lock again, and then write. When the first thread runs again it will the clobber the register.

]]> By: web development company http://tdistler.com/2008/07/21/cc-using-bitfields-effectively/comment-page-1#comment-4516 web development company Wed, 07 Oct 2009 13:43:01 +0000 http://tdistler.com/?p=120#comment-4516 Hey, that was interesting, Great information here on bitfields. Thanks for writing about it Hey, that was interesting,

Great information here on bitfields.

Thanks for writing about it

]]> By: mattepiu http://tdistler.com/2008/07/21/cc-using-bitfields-effectively/comment-page-1#comment-4443 mattepiu Fri, 18 Sep 2009 07:24:51 +0000 http://tdistler.com/?p=120#comment-4443 In reply to nix: hum, yes and no. You should know when you shouldn't mask/cache (usually you shouldn't) and when you can do freely (for example to read the status of the struct just one time and then read the various flags of that register snapshot). But I have to agree that usually caching isn't a good idea for volatile variables. In reply to nix:
hum, yes and no.
You should know when you shouldn’t mask/cache (usually you shouldn’t) and when
you can do freely (for example to read the status of the struct just one time and then read the various flags of that register snapshot).

But I have to agree that usually caching isn’t a good idea for volatile variables.

]]> By: nix http://tdistler.com/2008/07/21/cc-using-bitfields-effectively/comment-page-1#comment-3588 nix Wed, 17 Jun 2009 15:41:57 +0000 http://tdistler.com/?p=120#comment-3588 The Example to mask "volatile" (in the "Performance Problems" ) should not be practised as volatile is having its own special purpose and masking this property will give unexpected behaviuor from the application. The Example to mask “volatile” (in the “Performance Problems” ) should not be practised as volatile is having its own special purpose and masking this property will give unexpected behaviuor from the application.

]]> By: mythic.glyph http://tdistler.com/2008/07/21/cc-using-bitfields-effectively/comment-page-1#comment-1601 mythic.glyph Wed, 25 Feb 2009 16:47:46 +0000 http://tdistler.com/?p=120#comment-1601 short & sweet. short & sweet.

]]> By: Tom http://tdistler.com/2008/07/21/cc-using-bitfields-effectively/comment-page-1#comment-778 Tom Tue, 29 Jul 2008 15:48:46 +0000 http://tdistler.com/?p=120#comment-778 Fixed. Thanks! Fixed. Thanks!

]]> By: random dude http://tdistler.com/2008/07/21/cc-using-bitfields-effectively/comment-page-1#comment-769 random dude Tue, 29 Jul 2008 05:32:08 +0000 http://tdistler.com/?p=120#comment-769 There appears to be an error in this blog post - ‘virtual’ should likely be 'volatile' There appears to be an error in this blog post – ‘virtual’ should likely be ‘volatile’

]]>