On 6/8/07, Tomasz Jankowski <[EMAIL PROTECTED]> 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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
