Re: [PATCH ARM v3 7/7] mini-os: initial ARM support

[Thomas Leonard <talex5@gmail.com>]

On 17 June 2014 23:53, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> Thomas Leonard, le Tue 17 Jun 2014 14:47:16 +0100, a écrit :
>> I'm not sure what the difference between the synch and non-synch
>> versions is supposed to be. Currently, I'm just doing:
>
> The synch version provides memory barriers (and can thus be used for
> synchronization of other things). The non-synch version only provides
> atomicity.

OK, so does that mean that e.g. this comment in x86/os.h is wrong?

/**
 * test_and_clear_bit - Clear a bit and return its old value
 * @nr: Bit to clear
 * @addr: Address to count from
 *
 * This operation is atomic and cannot be reordered.
 * It also implies a memory barrier.
 */

>> I used __ATOMIC_SEQ_CST as the memory model as that was the safest
>> option, but maybe it's overkill.
>
> The synch_ versions provide a full memory barrier, so seq consistency is
> fine. The non-synch versions can use a completely relaxed memory model.
>
>> The main user of these operations was gic.c, but it turns out that the
>> atomic versions don't work here as the GIC registers aren't regular
>> memory. So I replaced those with non-atomic versions.
>>
>> Does this seem reasonable?
>
> I guess there are other ways to make sure no two threads are accessing
> GIC registers, so it is fine, yes.
>
> Samuel



-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel