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

Reply via email to