uff, I got a severe race condition, I managed to t...

# random

[elect]

uff, I got a severe race condition, I managed to take out 99% of times using @Synchronized but I still get it from time to time..

[uli]

elect: so i guess we can still call it broken 😉

[elect]

Is it broken? Oh god, then is not me?

[elect]

@uli

[uli]

Well, my point is, concurrency is hard to get right. Without seeing any code I would guess, that you have left some small window for a race in your 'improved' synchronisation

[uhe]

I'm using @Synchronized quite extensively and I haven't observed any bugs

[uhe]

all that does is add the `synchronized`modifier, same as in java

[elect]

I'll post on stackoverflow then, it's not short

[uhe]

@elect Are you aware that you are synchronizing on different objects?

[uhe]

@Synchronized uses this as monitor, your synchronized(lock) {} code uses a different one (namely the supplied lock)

[elect]

ok, let me try

[elect]

yep, that was another mistake of mine, but the main problem appear to be that the pools variables were leaking outside the classes

[elect]

however, if you want to answer that, I'll accept it @uhe

[uli]

http://stackoverflow.com/a/42975872/6359940

[uli]

Looks like you already found out about the leaking matrix in viewPole.calcMatrix()

[uli]

how about getting viewPole.calcMatrix() and objectPole.calcMatrix() at different times (i.e. in different synchronized blocks). Could this be an issue?

[uli]

And why to you declare the input methods as synchronized at all? If they are already called under the synchronized(lock)?

[elect]

exactly, that was the most problem

[elect]

thanks for your help and the tips btw 😉

[uli]

Welcome