<@U3SK5B492> I'm doing some theory crafting here. ...
# kotlin-natives
spierce7
10/18/2018, 1:13 PM@olonho I'm doing some theory crafting here. If I were to store an
NSMutableArrayList<>spierce7
10/18/2018, 1:13 PM Copy code
internal actual class LockedRef<T> actual constructor(
private val ref: T
) {
internal val lock = NSRecursiveLock()
actual inline fun <R> accessAtomically(block: (T) -> R): R {
lock.lock()
try {
memScoped {
return block(ref)
}
} finally {
lock.unlock()
}
}
}spierce7
10/18/2018, 1:24 PMExample Usage:
Copy code
internal class Test() {
val ref = LockedRef<List<Any>>(NSMutableArray() as List<Any>)
init {
freeze()
}
}s
svyatoslav.scherbina
10/18/2018, 1:26 PMThis should work properly.
Btw, your
memScopeds
spierce7
10/18/2018, 1:31 PMI put in in there to try and circumvent a race condition I was told about.
spierce7
10/18/2018, 1:33 PMI was told that the reference counting to my locked reference will actually decrement after the lock is unlocked, thus allowing a race condition. I tried to circumvent that with
memScopedmemScopedk
kpgalligan
10/18/2018, 1:36 PMI'm actually doing some mem tests now, so I'll see if I can cause the race condition
kpgalligan
10/18/2018, 1:36 PMI did get that to happen months ago, but the situation may be different now...
s
svyatoslav.scherbina
10/18/2018, 1:43 PMmemScopedk
kpgalligan
10/18/2018, 1:44 PMI was saying that leaving the function will trigger a decrement, and if the 'ref' isn't frozen, it'll be a race condition (potentially)
kpgalligan
10/18/2018, 1:45 PMdecrement of ref count
kpgalligan
10/18/2018, 1:58 PMI could be wrong, but it looks like there's a new feature that checks reference ownership on non-frozen objects, which will prevent this from working regardless (although I may be reading Memory.cpp wrong)
kpgalligan
10/18/2018, 1:59 PMkpgalligan
10/18/2018, 1:59 PMFails with...
kpgalligan
10/18/2018, 1:59 PMUncaught Kotlin exception: kotlin.native.IncorrectDereferenceException: illegal attempt to access non-shared sample.SampleTestsIOS.LockedRef@da400538 from other thread
at 0 test.kexe 0x000000010ad188e6 kfun:kotlin.Exception.<init>(kotlin.String?)kotlin.Exception + 70
kpgalligan
10/18/2018, 2:00 PMThat's good. Earlier versions of K/N would let you share non-frozen data and cause a race condition. Looking at git, the relevant code in Memory.cpp is pretty recent
s
svyatoslav.scherbina
10/18/2018, 2:00 PMYour code lacks lock freezing, like in
Testk
kpgalligan
10/18/2018, 2:01 PMAh, OK
s
svyatoslav.scherbina
10/18/2018, 2:01 PMObjective-C class instances are opaque for Kotlin object freezing.
k
kpgalligan
10/18/2018, 2:04 PMOK. I think I'm lost on how you'll be able to put a kotlin, non-frozen piece of state into the locked ref, which is the goal. Obviously Objc interop isn't affected by freezing, but now you need to add a value into that mutable array that is not frozen
kpgalligan
10/18/2018, 2:04 PMIN the original post, internal actual class LockedRef<T> actual constructor(
private val ref: T
kpgalligan
10/18/2018, 2:05 PM'ref' isn't frozen and is intended to be passed around to multiple threads with a lock around it
kpgalligan
10/18/2018, 2:05 PMYes?
kpgalligan
10/18/2018, 2:07 PMWe're having dual conversations, public and private
kpgalligan
10/18/2018, 2:07 PMThe goal, ultimately, is to have non-frozen data shared, backed by a lock
kpgalligan
10/18/2018, 2:08 PMIf that is the goal, the next step is to put data into that array inside of "LockedRef". However, whatever gets put in there, if its a kotlin object, would not be frozen.
o
olonho
10/18/2018, 2:09 PMas long as it is detached, just use lockless
AtomicReference<DetachedObjectGraph<T>>k
kpgalligan
10/18/2018, 2:09 PMI agree
kpgalligan
10/18/2018, 2:09 PMScott doesn't, which is how we got here 🙂
o
olonho
10/18/2018, 2:10 PMso he just wants to circumvent K/N safety mechanisms 🙂?
k
kpgalligan
10/18/2018, 2:10 PMYes
o
olonho
10/18/2018, 2:10 PMthen I would recommend to store data in C/Objective-C structure
k
kpgalligan
10/18/2018, 2:10 PMI'm relaying my same attempts in May/June, which I've ultimately abandoned
o
olonho
10/18/2018, 2:11 PMolonho
10/18/2018, 2:12 PMand just access the data from shared C memory
olonho
10/18/2018, 2:12 PMshared mutable Kotlin objects are not supported
k
kpgalligan
10/18/2018, 2:13 PMYes, that ^
s
spierce7
10/18/2018, 2:14 PM@olonho So it's not safe / won't work?
o
olonho
10/18/2018, 2:15 PMit does not work and is not safe
s
spierce7
10/18/2018, 2:15 PMCan you explain what will go wrong, for my own learning?
o
olonho
10/18/2018, 2:17 PMmemory manager will not be able to collect cyclic garbage, race conditions of all kinds may happen
s
spierce7
10/18/2018, 2:24 PMAlright, I'll swap it to use atomic
k
kpgalligan
10/18/2018, 2:25 PMAnd detached, if not freezing
s
spierce7
10/18/2018, 2:26 PMHow would I ensure it only gets attached to 1 thread at a time?
k
kpgalligan
10/18/2018, 2:26 PMLock
kpgalligan
10/18/2018, 2:26 PMAs you're doing now
kpgalligan
10/18/2018, 2:27 PMYou'll need to attach and detach in that single operation each time (which is why I got excited then less excited about detach)
s
spierce7
10/18/2018, 2:27 PMmeh. I'll just go immutable atomic
k
kpgalligan
10/18/2018, 2:27 PMDetachedObjectGraph is disposable. You can't "detach again" after attaching, so you need the atomic ref to change the instance
4 Views