Re: multi thread app and often variable accessing

["Jonathan Winterflood" <jonathan winterflood gmail com>]

On 6/8/07, Tomasz Jankowski <tomcioj gmail com> wrote:
> In fact I write library, but it's based on GLIb, so my library will be
> available only on platforms where GLib is available - problem resolved
> itself ;P Returning to main problem, maybe for sure, I will add another
> mutex used only for reading or changing status variable. It will be more
> expensive but maybe safer.
> --
> Cya!
> Tom


> available only on platforms where GLib is available
there's nothing stopping Glib being available on 8-bit systems [not the fact
they are 8-bit at any rate]

> you will end up locking and unlocking mutexes anyways
I meant that g_atomic* will do the locking for you

> I will add another mutex used only for reading or changing status
variable. It will be more expensive but maybe safer.
I think glib will be fine, just that you
will revert to low performance on really old/rare/weird systems

googling to find the atomic functions, I stumbled upon this:
http://www.nabble.com/Mutex-or-atomic-operations-for-multithread-app--t2612916.html
> If you don't know what memory ordering, barriers, etc. [...]
Indeed I don't know what these are either. Any chance that someone does?


Begin Curiosity:
> Also, the hardware must have something like the Pentium CMPXCHG8B [...]
Is it not
sufficient to be able to write an int in one single bus access? ie
have a 32-bit wide data bus
Or is that exactly the point? :D

> MOV instructions with a bus-lock prefix, which is slow.
OK, I guess it'd be faster (and leaner) than using a mutex though
But that can't be done in pure C, right?

End curiosity

Cheers,
Jonathan

--
<Morpheus> linux, c'est une question de VI ou de MORE