https://kotlinlang.org logo
#random
Title
# random
e

elect

03/22/2017, 10:04 PM
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..
u

uli

03/22/2017, 11:11 PM
elect: so i guess we can still call it broken 😉
e

elect

03/23/2017, 8:19 AM
Is it broken? Oh god, then is not me?
@uli
u

uli

03/23/2017, 9:06 AM
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
u

uhe

03/23/2017, 9:07 AM
I'm using @Synchronized quite extensively and I haven't observed any bugs
all that does is add the `synchronized`modifier, same as in java
e

elect

03/23/2017, 9:11 AM
I'll post on stackoverflow then, it's not short
u

uhe

03/23/2017, 10:34 AM
@elect Are you aware that you are synchronizing on different objects?
@Synchronized
uses
this
as monitor, your
synchronized(lock) {}
code uses a different one (namely the supplied
lock
)
e

elect

03/23/2017, 10:35 AM
ok, let me try
yep, that was another mistake of mine, but the main problem appear to be that the pools variables were leaking outside the classes
however, if you want to answer that, I'll accept it @uhe
Looks like you already found out about the leaking matrix in viewPole.calcMatrix()
how about getting viewPole.calcMatrix() and objectPole.calcMatrix() at different times (i.e. in different synchronized blocks). Could this be an issue?
And why to you declare the input methods as synchronized at all? If they are already called under the synchronized(lock)?
e

elect

03/23/2017, 1:30 PM
exactly, that was the most problem
thanks for your help and the tips btw 😉
u

uli

03/23/2017, 1:53 PM
Welcome