Can’t Lock() in RPA

For security and performance reasons, we often review what bots are doing and review any rejected bots to see how things are going.   When a bot is rejected, it is typically easy to spot the exact reason when looking at the code, but sometimes it’s not so apparent. 

By far, the biggest case that I see is using the Lock keyword.  For example:

    1: lock (someobject)
    2: {
    3:     //synchronized code
    4: }

On the surface, it’s not apparent this would be a rules violation, and in the vast majority of cases, it is fine.  But under the covers, it calls Monitor.Enter() in the System.Threading namespace (known as compiler syntactical sugar), and we don’t allow anything in that namespace to be called. 

The question we have internally is:  should we review the rule and make exceptions to specific calls?

In this case, there’s no reason to use such code in a bot.  The only time you’d need to is if your bot has a static method/object reference, but that’s a bad idea in a bot because it will lead to unpredictable results.  Your bot should have only instance members.   

So what’s the correct way?   Locking is a typical pattern (and a good habit) in object creation where there’s a risk of concurrency causing an issue.  Even if there is no risk, many developers are careful particularly with singletons to be sure of thread safety by using locks.  In the case of developing a bot, the best way to do this is in the bot’s constructor without any lock/monitor.  

Questions or feedback?  Let us know!