Rules DSL is not Java and in many respects it is unlike other programming languages. When you try to structure your coffee in ways you after used to work functions and data structures cobbled together from lists and maps and especially if you try to implement synchronization yourself they are coffee smells. Rules DSL doesn’t like coding structures like these and your coffee will be unnecessarily long, hard to maintain, and brittle.
So, if you are already a programmer I suggest looking into JSR223 Rules. It lets you build rules using Jython, JavaScript, or Groovy and it supports all of these sorts of coming common programming approaches.
If you are willing to step back and change how you approach coding your rules you can side step a lot of problems like theses and end up with short, easy to understand, and maintainable rules that don’t have these sorts of problems. But it is quite a challenge for a lot of people who already know how to program and it isn’t worth the effort for a lot of them.
If you must have a shared structure like this, then use a thread safe one like ConcurrentHashMap (Java Platform SE 6). You really need to go out of your way in Rules DSL to:
- make your Rules run as fast as possible
- not block other rules from running
See (OH 1.x and OH 2.x Rules DSL only] Why have my Rules stopped running? Why Thread::sleep is a bad idea for details.
Actually, it can because locking doesn’t seem to work very well with Rules DSL in general over and above the problems with locking up long running rules when the locks to work.
But assuming that your locks are working doesn’t mean that all of OH’s locks are working. If I had to guess, I’d first look to see if gWallSwitch.members is using a thread safe List. I suspect that the list is being monkeyed with while your findFirst is running.
I’ve only seen one other person report this as a problem and I’ve never seen it myself so I can’t say why you might be seeing it or if that is even relevant.