On 24 Jan 2008, at 12:48 AM, Adam R. Maxwell wrote: > > On Wednesday, January 23, 2008, at 02:13PM, "Christiaan Hofman" > <[EMAIL PROTECTED]> wrote: >> >> On 23 Jan 2008, at 11:07 PM, Adam R. Maxwell wrote: >> >>> >>> On Wednesday, January 23, 2008, at 12:24PM, "Christiaan Hofman" >>> <[EMAIL PROTECTED]> wrote: >>>> Is it safe to use the value as the first argument in >>>> OSAtomicCompareAndSwap32, as in OSAtomicCompareAndSwap32(value, 0, >>>> &value) ? And/or should there be a preceding OSMemoryBarrier() ? >>> >>> It might be safe, but I think it's more clear just to pass in the >>> expected value (since we always ignore the return value, it doesn't >>> much matter anyway). I think it's better to use >>> OSAtomicCompareAndSwap32Barrier() in all cases, though. >>> >> >> I don't mean this as opposed to using an explicit value. what I mean >> is: is it safe to use a value we use over threads in this place in >> this way at all (because we do in some places)? > > I understood the question. I'll rephrase my answer: I don't know > for sure. You might be able to look at the kernel source and > figure it out. Incidentally, where do we do this? AFAIK we pass > constants to the CAS functions. >
E.g. in BDSKSharedGroup (that one looks wrong, as that is definitely not aligned, the other tyhread may come in between the assignment of oldVal and the OSAtomic function). And in BDSKFileSearchIndex. >> I know the last >> (pointer) argument is accessed in a thread safe manner, but are the >> other arguments accessed in a thread safe manner? Arguments may not >> be fetched at the same time a function is executed in general. > > The volatile keyword should defeat compiler optimization, but I > don't think you can guarantee that another thread won't change the > value you're passing before the CAS, even with a barrier. You'd > need a lock for that. So probably it is best in general not to use it, at least for switches. Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop