use AsyncReaderWriterLock inside grain method

[slawomirpiotrowski]

Hello,

I'm trying to use AsyncReaderWriterLock inside my grain method. (Microsoft.VisualStudio.Threading.AsyncReaderWriterLock)
Microsoft.VisualStudio's licence is now MIT so we can use it for normal applications too.

AsyncReaderWriterLock is a nice thing to allow fast reader writer lock that is awaitable. I'm trying to use it inside my grain method (my writer is inside the grain while my reader is outside of the grain), but leads to exceptions when using Orleans functions after await for the lock.

It causes InvalidOperationException: Activation access violation. A non-activation thread attempted to access activation services.
Exception is thrown as soon as I try to access State of the grain after await AsyncReaderWriterLock.WriteLockAsync()

I already have a work around: await Task.Run(async () => await _cacheUpdateLock.WriteLockAsync());
But I think it's not how it's supposed to be coded.

I think I am expected to build a JoinableTaskFactory and pass it as argument when creating AsyncReaderWriterLock, but I can't find a way for it to work correctly with Orleans. Any ideas?

[ReubenBond]

It sounds like AsyncReaderWriterLock does not respect the TaskScheduler like it's supposed to.
When you await it, I assume you're awaiting it normally, not calling ConfigureAwait(false). Is that correct?

[slawomirpiotrowski]

Yes, I do a normal call to await for write lock like this:
var releaser = _cacheUpdateLock.WriteLockAsync();
later when releasing it I can issue
await releaser.DisposeAsync();
inside finally block.
(or use a using construct)

What have surprised me is that direct acquiring write lock inside grain method causes problems.

I know AsyncReaderWriterLock is playing some tricks to avoid main thread deadlock in case it was used by GUI applications. I think it might be causing problems here.

Maybe I should try to find another asynchronous reader writer lock implementation somewhere. I'm not bound to this implementation. I just use bare acquire / release write lock and acquire / release read lock. No upgrading reader locks to write locks and no nested locks so I don't really need to care about deadlocks.