On Sun, 20 Jun 2004, Oliver Neukum wrote: > > synchronize by a lock then it will always see the correct value, since the > > unlocking functions -- up() and spin_unlock() -- include write barriers. > > The issue is not the pointer itself. The problem is the memory the pointer > is pointing to. Iff the new pointer is returned the caller can expect that > that area of memory is initialised. Therefore the barrier must be before > the assignment. If you depend on the lock's barrier there's a window > in which the assumption is not necessarily true.
I don't see the problem. If the other processor synchronizes properly then the write barrier in the unlock function will guarantee that both the pointer and the memory it points to are initialized. Unless the first processor doesn't initialize the memory area until _after_ it has released the lock -- but in that case you shouldn't expect the area to be initialized. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
