runtime: Big slowdows with runtime.Gosched/runtime.GOMAXPROCS and scheduling(?).

[gopherbot]

by Vova616:

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
http://play.golang.org/p/pZ49yypAqM

What is the expected output?
finish in less than 1s

What do you see instead?
finishing after 10s+

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
windows 7 64bit

Which version are you using?  (run 'go version')
go version devel +5260abd6df41 Sat Mar 30 19:05:00 2013 +0800 windows/amd64

Please provide any additional information below.

Uncomment line 97 to make it run 50-500 times faster. (30ms vs 16s)
Replacing ReadAll with ReadAll2 will show the bug even with the uncommented line 97.
runtime.GOMAXPROCS(1) will fix the bug when using ReadAll or ReadAll2.
This is not happening in 1.0.3.

[dvyukov]

Comment 1:

Don't use Gosched() for performance critical code.
When you use Gosched() runtime has absolutely no idea what you want and what to schedule.
Also as far as I see, the program contains several data races, the program can be broken
with subsequent Go releases.

Status changed to WorkingAsIntended.

[gopherbot]

Comment 2 by Vova616:

If Goscheds should not be used in performance critical code I think we should provide a
function or a something that can be used in such situations but I'm sure you already
know it.
will Preemptive scheduling you talked about will solve this? if it does it can be a
strong evidence that we do need it or some kind of solution to this kind of situations.
I don't think solving the data races will change the result by much.
but I might be wrong, Thanks :).

[dvyukov]

Comment 3:

> If Goscheds should not be used in performance critical code I think we should provide
a function or a something that can be used in such situations but I'm sure you already
know it.
There are channels and sync.Mutex/Condition.
Perhaps an effective version would use sync.RWMutex to synchronize between the writer
and readers, a bounded list/array of buffer to not block the writer, atomic counter to
count finished readers for each block and a condition variable to block on empty/full
list.

[dvyukov]

Comment 4:

> will Preemptive scheduling you talked about will solve this?
No, it won't.

[gopherbot]

Comment 5 by Vova616:

Originally similar code was used in shared memory by file mapping(readers is different
processes and writer is one process), I wasn't sure channels/any kind of locking will
work if I put them on shared memory so I used atomic.
anyway, I might try different approaches, thanks.

[dvyukov]

Comment 6:

Ah, I see.
I think you can take the sync.Mutex/RWMutex/Cond algorithm, replicate it and replace
semacquire/semrelease with some OS blocking mechanism (e.g. on Linux I would use Unix
socket with 1-byte write as semrealase and 1-byte read as semacquire, I am not sure what
is the best way to do it on Windows, perhaps just local socket). This will give you
user-space fast-path and proper blocking for slow-path. In contrast to sync.Mutex it may
benefit from some limited active spinning before resorting to socket.

[alexbrainman]

Comment 7:

All windows sync objects (event, mutex) can be shared between different processes - just
use DuplicateHandle. You just need way to pass these handles between processes to get
you started. As comand line parameters perhaps. You can also use shared memory and named
mutex. Alternatively, soctets could be as fast. I don't know.
Alex

[dvyukov]

Comment 8:

Note that OS mutexes/events/semaphores as well as plain Read/Write will consume threads
during blocking. While unix/local socket will reuse net poller, and only consume
goroutines.

[gopherbot]

Comment 9 by Vova616:

I just tried some tests with LockSpin using Gosched/sleep and they were running pretty
fast (faster than sync.Mutex), I have checked the running speeds and its not the Gosched
thats slow(well its but not always),
the readers spends too much time in the loop (line 43).
Ex:
I have 4(8) cores and I'm setting runtime.GOMAXPROCS(8) and there are 20 readers trying
to read, they will often be greedy inside the Gosched loop and not let the other
readers/writer to run, but if I will set runtime.GOMAXPROCS(>=22) it will make them run
evenly.
Gosched times called per reader and the run times (there are 20 readers):
runtime.GOMAXPROCS(1) - 9999 - 36ms
runtime.GOMAXPROCS(8) - ~7000000 - 14s
runtime.GOMAXPROCS(22) - ~13000 - 57ms
So Gosched usually is very fast but under some conditions Gosched can take some
time(1-6ms) and not let the readers/writer(other goroutines) to continue.
If I change Gosched to sleep(1) the sleep can sometimes take up to 50ms to complete.
I also tried to reproduce it in different ways using Gosched/sleep and atomic and had no
luck.

[dvyukov]

Comment 10:

>and its not the Gosched thats slow(well its but not always),
>the readers spends too much time in the loop (line 43).
Yeah, but the line 43 is executed lots of times because of Gosched().
Ideally you:
- check the ready condition
- if not ready, block the goroutine until the condition is true

[gopherbot]

Comment 11 by Vova616:

Yes but its executed lots of times because its not giving the other readers to run and
change the condition so its keeping executing lots of times unless I change
runtime.GOMAXPROCS to small value or bigger than work value.
why cant GOMAXPROCS 21 spread the work like GOMAXPROCS 1 or even 2, and why its
spreading the work a lot better when its 22.
the jump from 21 to 22 is 500 times faster.
also with 80 readers and GOMAXPROCS 82 it sometimes can finish the work in less than 1
sec and sometimes can take up to 10 sec.
anyway, I won't argue and maybe I'm not understanding/misunderstanding something, but I
think its not working as intended.
thanks.