On February 1, 2015 06:08:27 PM Andrew Deryabin wrote: > Hi Tim, > > 01.02.2015 16:15, Tim E. Real wrote: > > On February 1, 2015 06:45:22 AM Andrew Deryabin wrote: > >> Hi again, Tim. > >> > >> Just wondered, if this operation in `muse_atomic_set` can be considered > >> safe? (i386 case) > >> > >> `v->counter = i;` > >> > >> It seems that it can be easily interrupted. > >> > >> Regards, > >> Andrew > > > > I have read that modern processors such as Intel do such > > > > operations atomically so there's no need to take > > care of such things in code. > > It's nice if it's so.
I did read that, and I know this: It's been years since I saw a 'concurrent' access problem in MusE, and trust me there are several places where we still casually use some simple global variables concurrently without any regard to locking. So I always had a suspicion that it was OK to do this with for example simple boolean variables. Hope that's correct. But as you can see I'm trying to start using lockable variables, just in case. Sometimes there's just no point in setting up a whole inter-thread ring buffer / pipe just for one global boolean flag variable. Seems to me occasionally quickly locking a simple operation shouldn't hurt too much, right? But as I say below, it's more about timing... As mentioned Florian wanted to start a new MusE based on lockable lists, of the kind like say Boost I think, but he said another one I can't recall. Currently instead of locks we just verrry carefully time EVERYTHING. It means we just hope that any desired realtime operations commands can be completed before the next callback, else xruns. All real time operations commands MUST be done through the GUI which waits until (a group of) real time operations have completed. You can't even initiate a real time operation from ANOTHER thread, it must be done through the GUI for correct synchronization. We have some reverse help with RT -> GUI messaging with the use of QSocketNotify. Thankfully it ALSO provides a synchronization mechanism in that these are GUI event loop messages so we know our GUI thread is 'clear and ready' for the message. So recently I added something I called 'pending fast RT operations' where I broke our operations down and only execute the absolute bare required code in RT, say like adding an item to a list, the rest is done before or after in GUI thread. You can see there's still room for trouble if say adding a list item causes a re-allocate. It's about as fast as it can be so far... I mean at some point there HAS to be allocation of some kind, no getting around it unless you want fixed ARRAYS ;-) But... MusE has a memory POOL mechanism for some of our real time safe STL containers. But not all of them, and not all the ones I'm speaking of which are 'operable'. I was thinking expanding our use of pools is a good solution for an xrun- free current MusE. Just load up the pools with enough memory at start and away we go! The object: No allocation /ever/ for our realtime-safe lists. Make their size scaleable as user settings, just in case. > But the strange thing is that increment operation > is prefixed with asm lock though it's just 2 operations: > mov atomic_addr, %edx > inc [%edx+counter_offs] > but to assign value to memory address there should be at least 3 operations: > mov newval, %eax > mov atomic_struct_addr, %edx > mov [%edx+counter_offs], %eax > > But may be I'm wrong. > > I made changes to muse_atomic.h today. The changes include: > > 1. change i386 to more common __i386__ though boths are known to gcc and > clang > 2. replace pthreads calls with builtin atomic operations > 3. turn on asm atomic operations for both i386 and x86_64 > > The most noticeable correction was excluding pthreads locks from the > code and replacing them with atomic operations. But after that I > realized, that these asm operations for inc/dec are suitable for x64 > arch too and work there just great. I checked modifications both on > clang and gcc. On my x64 system cpu usage while playing projects with > wave tracks decreased by ~0.5% for 3 mono audio tracks (I've compared > pthreads variant with gcc atomic functions and then with pure asm > versions - the last is the fastest). > > Can you check new code? What do you think about it? > > Regards, > Andrew OK Cool, I had read about those functions but never thought to use them, in my broad search on lockable lists and so on. Now they make a lot of sense in this light. Not sure about the assembly, I find linux assembly really hard to follow in after many years of assembly coding in windows. Tested: With one of my audio/midi songs tonight, seems OK. Will keep an eye out for trouble. Thanks. Tim. > > > The i386 check is to see if it's an actual Intel processor > > > > and therefore OK to use that code. > > > > Now, whether it is safe on an actual old 386 processor, > > > > not sure, maybe we should change it to __i686__ > > or something... > > > > I thought I read generally only Pentium supported this feature. > > > > The issue for me is I know that my compiler knows about this > > > > i386, but my IDE shows it is not recognizing it. > > > > I will check actual object code to see what's going on. > > > > Tim. > > > >> 01.02.2015 05:54, Andrew Deryabin wrote: > >>> Hi Tim, > >>> > >>> Just made a check: > >>> > >>> ------------ > >>> Konsole output > >>> gcc -m32 -dM -E -x c /dev/null | grep 386 > >>> Konsole output > >>> #define __i386 1 > >>> #define __i386__ 1 > >>> #define i386 1 > >>> ------------ > >>> ------------ > >>> Konsole output > >>> clang -m32 -dM -E -x c /dev/null | grep 386 > >>> Konsole output > >>> #define __i386 1 > >>> #define __i386__ 1 > >>> #define i386 1 > >>> ------------ > >>> > >>> So it seems, that all of these macros are defined both on gcc and clang. > >>> > >>> Regards, > >>> Andrew > >>> > >>> 31.01.2015 23:58, Tim E. Real wrote: > >>>> Hi. > >>>> > >>>> I asked this before but can't remember, I think some said they got > >>>> > >>>> different results: > >>>> Can you guys please simply check in the (new) file muse_atomic.h, > >>>> > >>>> and tell me if the sections marked "#ifndef i386" are active? > >>>> > >>>> (I created this file and simply moved some code from another file into > >>>> it.) > >>>> > >>>> On all my systems (currently KUbuntu, Intel) the "#ifndef i386" > >>>> sections > >>>> > >>>> have been active (as viewed in KDevelop) for as long as I can > >>>> remember. > >>>> > >>>> Yet the compiler actually knows about this i386 define - you can see it > >>>> > >>>> in a printout of a simple "test for compile defines" program. > >>>> > >>>> I do not know if the compiler is actually compiling THOSE sections. > >>>> I would need to check compiled objects... > >>>> Just that KDevelop shows the sections as active. > >>>> > >>>> I want to change the define test to "#ifndef __i386__" which works. > >>>> But is that really correct? SHOULD it be i386 not __i386__? > >>>> > >>>> This issue could be important, it means MusE might gain a good > >>>> > >>>> speed boost by using processor atomic features instead of calling > >>>> pthread_mutex_lock() ! > >>>> > >>>> Tim. > > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
