Re: multi thread app and often variable accessing
On Fri, 2007-06-08 at 19:41 -0600, Jim George wrote: > > 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 > > > No, in most cases, if you want to atomically increment or decrement a > value (for example, a semaphore or ref count) without locking, you > have to read the value, increment it, then write it only if it's not > changed. The write and check to see if it's not changed must be > atomic, this is where CMPXCHG comes in. > > > >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? > > > Maybe, but I don't see how any end-user program (such as one with a > GTK interface) would benefit from the small speed increase. Put such > stuff in another program which merely reports its progress to the gtk > GUI program through a socket or pipe. Another effect of using the CMPXCHG is that it forces the memory manager to read the value from memory and not cache, and write through the cache to physical memory on write. This is important in the case where you've got more than one core running threads on your code: Each core has it's own cache. If the instruction didn't force a sync with physical memory, your code would break. // Wally -- [EMAIL PROTECTED] Office: 619.278.2084 Cell: 619.990.2286 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: multi thread app and often variable accessing
> 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 > No, in most cases, if you want to atomically increment or decrement a value (for example, a semaphore or ref count) without locking, you have to read the value, increment it, then write it only if it's not changed. The write and check to see if it's not changed must be atomic, this is where CMPXCHG comes in. > >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? > Maybe, but I don't see how any end-user program (such as one with a GTK interface) would benefit from the small speed increase. Put such stuff in another program which merely reports its progress to the gtk GUI program through a socket or pipe. > End curiosity And Yeti's right, this stuff can lead to months of head scratching unless you know what you're doing. I know I don't, so I'll not potentially mislead you any more. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: multi thread app and often variable accessing
On Fri, Jun 08, 2007 at 09:27:38PM +0200, David Nečas (Yeti) wrote: > > Attempts to use atomic operations without considering memory [*] > access ordering guarantee subtle bugs... [*] as a substitute for locking. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: multi thread app and often variable accessing
On Fri, Jun 08, 2007 at 08:51:08PM +0200, Jonathan Winterflood wrote: > > > If you don't know what memory ordering, barriers, etc. [...] > Indeed I don't know what these are either. Any chance that someone does? See Documentation/memory-barriers.txt in Linux source code, on-line available for instance at http://www.mjmwired.net/kernel/Documentation/memory-barriers.txt for a good overview of the concepts and issues. The later parts of the document are kernel specific, but you may get more information than you want even before you get to these parts. Attempts to use atomic operations without considering memory access ordering guarantee subtle bugs... Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: multi thread app and often variable accessing
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 -- 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
Re: multi thread app and often variable accessing
> On 6/8/07, Tomasz Jankowski <[EMAIL PROTECTED] > wrote: > > > > Hi! > > > > I'm working on small multi thread application based on Gobject. In one of > > my > > objects I have integer variable, which determine current object's status. > > The problem is, that I need to read it's status really often, so it will > > be > > to expensive to lock and unlock mutex all the time. Can I use there atomic > > operations provided by GLib instead of mutex locking and unlocking system? > > I > > mean, if g_atomic_get and g_atomic_set would not occur any problems, when > > I > > will try to access the same variable from two thread at the same time? > > > > -- > > Cya! > > Tom On 6/8/07, Jonathan Winterflood <[EMAIL PROTECTED]> wrote: > Hi, > > As far as I understand, g_atomic_int_get/set will do the job > just fine, as long as you're sure the only part that needs to be > atomic is the getting and setting. > However, if the hardware you are running on does not provide an atomic way > of getting/setting an int, (eg: int is an int32 and the hardware is 8-bit), > you will end up locking and unlocking mutexes anyways (but most systems > nowadays are 32bit+ anyways) > > Jonathan > Also, the hardware must have something like the Pentium CMPXCHG8B or it's newer cousins to do this "efficiently". I'm not sure exactly how it's done in glib, but normally, if such instructions dont exist, you need to issue standard MOV instructions with a bus-lock prefix, which is slow. -Jim PS, please don't top-post. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: multi thread app and often variable accessing
Hi, As far as I understand, g_atomic_int_get/set will do the job just fine, as long as you're sure the only part that needs to be atomic is the getting and setting. However, if the hardware you are running on does not provide an atomic way of getting/setting an int, (eg: int is an int32 and the hardware is 8-bit), you will end up locking and unlocking mutexes anyways (but most systems nowadays are 32bit+ anyways) Jonathan On 6/8/07, Tomasz Jankowski <[EMAIL PROTECTED] > wrote: > > Hi! > > I'm working on small multi thread application based on Gobject. In one of > my > objects I have integer variable, which determine current object's status. > The problem is, that I need to read it's status really often, so it will > be > to expensive to lock and unlock mutex all the time. Can I use there atomic > operations provided by GLib instead of mutex locking and unlocking system? > I > mean, if g_atomic_get and g_atomic_set would not occur any problems, when > I > will try to access the same variable from two thread at the same time? > > -- > Cya! > Tom > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
multi thread app and often variable accessing
Hi! I'm working on small multi thread application based on Gobject. In one of my objects I have integer variable, which determine current object's status. The problem is, that I need to read it's status really often, so it will be to expensive to lock and unlock mutex all the time. Can I use there atomic operations provided by GLib instead of mutex locking and unlocking system? I mean, if g_atomic_get and g_atomic_set would not occur any problems, when I will try to access the same variable from two thread at the same time? -- Cya! Tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
