> > No they're not. Both are just about equally expensive cpu wise, > > sometimes the atomic_t ones are a bit more expensive (like on parisc > > architecture). But on x86 in either case it's a locked cycle, which is > > just expensive no matter which side you flip the coin... > > But if a lock is used exclusively to protect a int variable, an atomic_t > seems to be more appropriate to me. Isn't it?
sounds like it... > Please, if you could, review the patches with this in mind: we aren't > changing any behaviour neither creating any weird lock scheme, we are > only doing two things: ... however you are NOT changing the behavior, which is EXACTLY my point; the current "lock emulation" behavior is wrong, all you're doing is replacing how you do the wrong thing ;) It's like having a bike with square wheels, and replacing a flat tire with one with air in, as opposed to replacing it with a round wheel... ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
