I have identified a serious bug with concurrent Csound. This is on
Windows 8.1 with the mingw64 build of Csound for 64 bit CPU
architecture. Detailed traces may be found below.

The problem appears to be related to a problem that I reported earlier
with the global mutex.

On Windows, exporting data elements such as the global mutex is not
straightforward. The global mutex should be brought into the Csound
engine and accessed only using the API.

In the meantime, I will take a closer look, as some of the other
problems were caused by failing to initialize the global mutex.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

B 55.500 .. 60.000 T 60.000 TT 60.000 M:   6259.3   5997.3
Score finished in csoundPerform().
inactive allocs returned to freespace
end of score.              overall amps:  16990.1  14026.2
0 errors in performance
Elapsed time at end of performance: real: 3.227s, CPU: 3.219s
8192 32768 sample blks of floats written to Xanadu.wav (WAV)

restore@sorabji MINGW64 ~/csound/examples
$ csound xanadu.csd -j2
Segmentation fault

restore@sorabji MINGW64 ~/csound/examples
$ gdb --args csound xanadu.csd -j2
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from csound...done.
(gdb) run
Starting program:
D:\msys64\home\restore\csound\mingw64\csound-mingw64\csound.exe
xanadu.csd -j2
[New Thread 6868.0x1680]
[New Thread 6868.0x1488]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6868.0x1488]
0x000007fd277c7740 in ntdll!RtlMultiAppendUnicodeStringBuffer ()
   from C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x000007fd277c7740 in ntdll!RtlMultiAppendUnicodeStringBuffer ()
   from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fd277bc5a5 in ntdll!RtlInitializeCriticalSection ()
   from C:\Windows\SYSTEM32\ntdll.dll
#2  0x000000006c5ef80c in csound_global_mutex_lock ()
    at D:/msys64/home/restore/csound/H/csGblMtx.h:113
#3  kperfThread (cs=0x1c80080)
    at D:/msys64/home/restore/csound/Top/csound.c:1464
#4  0x000000006c76db04 in pthread_create_wrapper ()
   from D:\msys64\home\restore\csound\mingw64\csound-mingw64\csound64.dll
#5  0x000007fd2702707b in msvcrt!isspace ()
   from C:\Windows\system32\msvcrt.dll
#6  0x000007fd27045e6d in msvcrt!_beginthreadex ()
   from C:\Windows\system32\msvcrt.dll
#7  0x000007fd24f71842 in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\system32\kernel32.dll
#8  0x000007fd277edf11 in ntdll!RtlUserThreadStart ()
   from C:\Windows\SYSTEM32\ntdll.dll
#9  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

More on this.

I have rewritten csGlbMtx.h to use pthread.h, which is used elsewhere
in Csound so there is no need to use the Windows threading functions
or indeed to have any conditional compilation.

-j now works, and indeed it works far better than before. Plain old
xanadu.csd with -j4 now shows a speedup of 2.6!


Regards,
Mike



-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sun, Apr 3, 2016 at 3:58 PM, Michael Gogins  wrote:
> I have identified a serious bug with concurrent Csound. This is on
> Windows 8.1 with the mingw64 build of Csound for 64 bit CPU
> architecture. Detailed traces may be found below.
>
> The problem appears to be related to a problem that I reported earlier
> with the global mutex.
>
> On Windows, exporting data elements such as the global mutex is not
> straightforward. The global mutex should be brought into the Csound
> engine and accessed only using the API.
>
> In the meantime, I will take a closer look, as some of the other
> problems were caused by failing to initialize the global mutex.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> B 55.500 .. 60.000 T 60.000 TT 60.000 M:   6259.3   5997.3
> Score finished in csoundPerform().
> inactive allocs returned to freespace
> end of score.              overall amps:  16990.1  14026.2
> 0 errors in performance
> Elapsed time at end of performance: real: 3.227s, CPU: 3.219s
> 8192 32768 sample blks of floats written to Xanadu.wav (WAV)
>
> restore@sorabji MINGW64 ~/csound/examples
> $ csound xanadu.csd -j2
> Segmentation fault
>
> restore@sorabji MINGW64 ~/csound/examples
> $ gdb --args csound xanadu.csd -j2
> GNU gdb (GDB) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-w64-mingw32".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from csound...done.
> (gdb) run
> Starting program:
> D:\msys64\home\restore\csound\mingw64\csound-mingw64\csound.exe
> xanadu.csd -j2
> [New Thread 6868.0x1680]
> [New Thread 6868.0x1488]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 6868.0x1488]
> 0x000007fd277c7740 in ntdll!RtlMultiAppendUnicodeStringBuffer ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> (gdb) bt
> #0  0x000007fd277c7740 in ntdll!RtlMultiAppendUnicodeStringBuffer ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> #1  0x000007fd277bc5a5 in ntdll!RtlInitializeCriticalSection ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> #2  0x000000006c5ef80c in csound_global_mutex_lock ()
>     at D:/msys64/home/restore/csound/H/csGblMtx.h:113
> #3  kperfThread (cs=0x1c80080)
>     at D:/msys64/home/restore/csound/Top/csound.c:1464
> #4  0x000000006c76db04 in pthread_create_wrapper ()
>    from D:\msys64\home\restore\csound\mingw64\csound-mingw64\csound64.dll
> #5  0x000007fd2702707b in msvcrt!isspace ()
>    from C:\Windows\system32\msvcrt.dll
> #6  0x000007fd27045e6d in msvcrt!_beginthreadex ()
>    from C:\Windows\system32\msvcrt.dll
> #7  0x000007fd24f71842 in KERNEL32!BaseThreadInitThunk ()
>    from C:\Windows\system32\kernel32.dll
> #8  0x000007fd277edf11 in ntdll!RtlUserThreadStart ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> #9  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Excuse this intrusion, but i was about to do some testing with -jN and
--sample-accurate, together with kmps=128. I would like to know if a speedup
of Csound will happen.

Does your solution in csGlbMtx.h affect a Linux build as well?



--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-dev-Serious-problem-with-j-tp5748445p5748479.html

Shouldn't, but let me know if it does.

Best,
Mike