On Thu, 2015-03-05 at 17:39 -0800, Andrew Fish wrote: > > On Mar 5, 2015, at 4:34 PM, James Bottomley > > <james.bottom...@hansenpartnership.com> wrote: > > > > On Wed, 2015-03-04 at 18:30 -0800, Andrew Fish wrote: > >>> On Mar 4, 2015, at 5:34 PM, Chen Fan <chen.fan.f...@cn.fujitsu.com> wrote: > >>> > >>> Hi Jeff, > >>> > >>> Thanks for your explanation, I didn't encounter any issue if leaving it > >>> there. > >>> > >>> I just think if use Volatile qualifier may cause the problem of > >>> performance. because > >>> access the value need to copy the address value from main memory to cpu > >>> cache > >>> each time and not use the cache. > >>> and IIRC, in a shared memory multiprocessor system, the cache coherence > >>> may > >>> keep the consistency of shared resource data in each processor local > >>> caches. > >>> if the value is updated by one processor in local cache, the copy of > >>> memory data in > >>> other processor caches will be marked as invalid. and then other > >>> processors read the > >>> value will access from the main memory. > >>> if I misunderstand, please correct me. :) > >>> > >> > >> Correction! > >> > >> Volatile in C has nothing to do with hardware and caching. It has to > >> do with the abstract memory model for the compiler as defined by the C > >> standard. The more aggressive the compiler optimizes the code the more > >> you are exposed to potential issues. If the compiler knows about all > >> the code in the program that accesses a variable it can assume that > >> memory location will only be changed by the compiler, and make > >> optimizations (like storing a pointer in a register). > > > > Just to say this in a stronger way: using a volatile keyword on data > > usually indicates a mistake in the program. > > +1 as too many people try to use volatile for thread sync, and thank is a bad > idea! > > > The reason is that all > > locking primitives are memory barriers (a memory barrier to a compiler > > means that all externally stored variables that are being housed in > > temporary storage are placed in stable storage on crossing a memory > > barrier). The only reason you would need a volatile primitive in SMP > > code is if the variable is being accessed without locking, so the first > > question should be "where's the lock that protects this data?". > > > 100% agree. The locks are memory barriers, but you are still exposed > to the C memory model between the locks (see example).
Correct, but because the variable is going to be stabilised before the unlock, it doesn't matter for the operation of an SMP system where you keep it before the unlock. That's the point of the "volatile considered wrong" argument: the concurrency visibility points of your system are supposed to be lock and unlock. If something depends on state visibility inside the critical sections (which would be the only reason you'd need a volatile), there's something wrong somewhere ... > So it kind of depends how much work you are doing between the lock and > unlock. You could argue doing a lot of work between the locks is a bad > design, but … Not really, although the larger the critical section, the more it may become a concurrency bottleneck. It doesn't matter how much work you do in the section. As long as no one would try to look at the results until the unlock, volatile is unnecessary. > I’m guessing its probably just over specification of the volatile. I > know I’ve had my vendors memory test stripped from my executable since > it tried to write to address 0. You get a little paranoid about NOT > using volatile if you write enough firmware. Well, remember I have a different background: OS drivers. We need the external visibility of IO accesses, but we get yelled at if we use volatile because it makes stuff slow, so we get used to using locking and memory barriers. James ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
