Tagging subscribers to this area:@mangod9
See info inarea-owners.md if you want to be subscribed.

CI errors are known

@kouvel I am just wondering - does F# have a special treatment for Lock too?

Also, should Monitor.TryEnter throw an error if Lock object is passed? so other CIL languages could realize they need a special treatment here

cc@vzarytovskii

lock in F# is just a function, which takes a lock object and a function. No special treatment.

lock in F# is just a function, which takes a lock object and a function. No special treatment.

From my understanding, the problem is - we now have this Lock type and it shouldn't be used (behind the scene) with Monitor type, otherwise if user defines aLock lock object and then mixes its usage withlock keyword or f# function (doesn't matter) with explicit TryEnter/Scope APIs they might run into terrible hard-to-repro bugs

Yea that's a good point. I'm not sure if there's a way to disallowLock-typed objects to be used statically with thelock function. At least that would be a deterrent but theLock type could also be easily casted away. Not sure if there is a good solution to that, thoughts?

A run-time check adds a bit of measurable cost to locking, and if done in thelock function may also increase code size because it seems to be inlined. Or maybe there should be some guidance such as not to useLock withlock in F#?