Re: Any plans for glib to contain atomic compare/exchange?

[Mike Hearn <m hearn signal qinetiq com>]

> To make changes to memory visible to other CPUs (for example changes to
> the pointers that constitute the backbone of linked lists).
> 
> Some architectures have a much weaker memory order than the x86 so memory
> barrier instructions are necessary (memory reads/writes are not reordered
> across memory barriers).

Ah, I understand now, thanks.

> Most people who post in gtk-app-devel-list barely know C.  Of those who
> do, pointers (especially function pointers) seem to be advanced
> higher-order magic.
> 
> I think it is better to have simple data structures in glib (and tell
> people to use mutexes to protect them if they use threads) than to give
> them more sharp tools to cut themselves on.
> 
> The people who know how to use these things correctly will also be able to
> code them up if they need them.

Yes, this is true, I suppose where performance is a concern copy and
paste could be used. I was mainly thinking it would be good from a
syntax point of view, if you only have some simple variables defining a
mutex for them is a bit annoying - but it's also quite rare. I wasn't
aware of these subtle issues with memory barriers either.

> Please note that despite your pretty impressive record (with Wine, for
> example) you didn't know about memory barriers either! :)

Yep, there's still so much to learn! :) Thanks for explaining it to me

-mike

-- 
Mike Hearn <m.hearn@signal.qinetiq.com>
QinetiQ - Malvern Technology Center