Thread Safety

[Polytehnitis]

As outlined in this paper "Enabling Robot Arm Motion with Multiple Objectives Through Agent Representation and Reasoning" (https://deepblue.lib.umich.edu/handle/2027.42/194610 ) SOAR is not thread safe. Has the issue been adressed?

[scijones]

In general, I would say no, but I welcome others' input.

@emgoeddel - Would you be able to provide some context here?

For general information about running Soar and threading, I can recommend this page: https://soar.eecs.umich.edu/development/soar/ThreadsInSML/

[Polytehnitis]

The issue is outlined towards the end of page 106 second paragraph in chapter 5.3.3.2 Integration with WM.

[scijones]

Thanks. To my knowledge, nothing has changed since that thesis.

To quote the page I linked: "The approach we've taken is to assume that the kernel is itself not thread-safe at all".

What is your prospective use case for Soar? We may have design patterns that mitigate this, depending.

[Polytehnitis]

Curently I am just building a robotic arm and planning to replicate the thesis and perhaps extending Rosie as much as I can. However, the subject of thread safety has also come up in the 44th Soar Workshop, in the presentation by Moritz Schmidt : Soar as Cognitive Control Unit for a Robot Task Delegation Interface based on ROS2. Slide 8, Chapter SoaROS: ROS2 Interface for Soar, section Requirements. https://raw.githubusercontent.com/SoarGroup/website-downloads/main/workshops/44/talk.2.pdf

[scijones]

I'll raise this with the group. A thread safe interface doesn't strike me as something I'll be able to just "whip into shape" in short order. But we have three folks now telling us that working with robots is hard because of this, so I can't ignore it. When we have a chance, I guess the way to do this is to create a wrapper around SML stuff? I'm open to suggestions, and I think I'll talk to @moschmdt .

[scijones]

In fact, I need to read up to what extent Moritz is basically already doing this. I'm ignorant at the moment.

[PLatCIC]

Here is the relevant paragraph referred to in the first comment of this issue from @emgoeddel's thesis:

The most salient issue is that Soar itself is not thread-safe. The find-trajectories
command, in particular, requires updates from multiple parallel threads that result in trajectory
information being converted into symbols in WM. When Soar runs at full speed, the
find-trajectories interface frequently crashes the architecture. This issue is well beyond
the scope of this dissertation, so our tests have been run with a 10ms delay in each Soar cycle to
limit the frequency of encountering this problem. In the long term, though, fixing the relationship
between the Soar kernel and multi-threaded modules like SVS+T is critical.

My interpretation of this is that this find-trajectories interface runs many threads, each of which on its own is trying to put things into WM. Whatever the callbacks are that actually change WM are the things that are not using a thread-safe mechanism to do those changes.

One approach to solving this problem would be simply to have the callback that changes WM set a thread lock, do its work, and then release the lock.

Another possible approach would be to thread-safely feed all those changes into a message queue, and then have a single thread that takes messages out of that queue and makes the actual WM changes.

All this assumes that all those threads out there do not depend on each other's changes to WM to work properly. If they were mutually dependent that would make things much worse. From what I can tell, I doubt that the find-trajectories threads mentioned here are mutually dependent.

In summary, it might be that for the find-trajectories problem could be solved simply by a thread-safe implementation of that interface without any major change to Soar or SML. My guess is that the claim

that Soar itself is not thread-safe

is a bit of an exageration.

[moschmdt]

I am aware of the issue, but so far I have not experienced any problems with that particular problem. I can only speak of my experiences with implementing and using soar_ros. However, I did not run any (stress) tests trying to break soar_ros by provoking threading issues.

Similar to what @PLatCIC suggests is already being used in soar_ros: A messaging queue approach in the SoarRunner that handles all the connections that need access to the Soar working memory and the kernel itself.

[aaron-mininger-cic]

In my experience interfacing Soar with robots via SML, threading issues have come in two major places:

1. Having external controls that can run/step/stop the agent (This is discussed in some length on )
2. Reading/writing working memory

I'll elaborate more on the second point. Let's imagine an SML layer connecting a Soar agent to some robotic interface. The middleware periodically receives updates from the robot or perception giving updates about the world that we want to put into the agent (via input-link or SVS). The kernel is running in its own thread and working memory can only be modified during an event callback (like BEFORE_INPUT_PHASE). If you try to directly edit working memory outside these callbacks, it can crash the agent.

So you need to somehow buffer these updates and only apply them during a callback. My approach generally has been to have a local representation of the world state. Given a perceptual update, it updates this state, and given an agent callback, it updates working memory using this state (with a lock to make sure they don't happen simultaneously). I've written some python code to make this a bit easier (such as https://github.com/Center-for-Integrated-Cognition/pysoarlib/blob/main/src/pysoarlib/SoarWME.py).

I'm not sure it would make sense to try and make the kernel thread safe, since I think this would impact performance and possibly stability. But, I could imagine creating a C++ helper library (similar to what I have done with pysoarlib) that would extend SML and make it easier for people to develop Soar agents and integrate with robotics.

[PLatCIC]

I concur with Aaron's suggestions. That buffering he suggests should solve the problem regarding WM.

[Polytehnitis]

Wouldn't buffering also make the system slower? If SOAR is used to controll multiple robots, simultaneously, that provide a constant stream of data about the external world state then wouldn't that cause the system to be overwhelmed with input without being able to send any outputs?

[PLatCIC]

I don't know that it will slow it down, since there will be less thread switching. However, if there is more data coming in than Soar is able to swallow, there would need to be some kind of filtering or compression of the perception data to get it down to a manageable bandwidth.

[Polytehnitis]

Imagine a factory full of these:
https://www.linkedin.com/feed/update/urn:li:activity:7360695154195808259/
Filtering of the perception data coming from all those robots and slow responce will probably cause the deterioration of the robots accuracy and/or speed. Reduced accuracy equals more defective products and and probably a dangerous environment for humans present. Reduced speed means less products being made.
Perhaps SOAR being single threded, when all new proccesors coming out focus on having as many cores and threads as possible, may be an outdated idea. But I guess that this belongs to a diferent thread.

[scijones]

"If SOAR is used to control multiple robots, simultaneously" -- well it depends on what you mean by that.

I can't speak impromptu for @moschmdt 's deployment, but a pattern I've often seen is that Soar controls one robot. And in settings where multiple robots/agents coordinate, there are literally multiple agents interacting. You can even have hierarchy, e.g., a captain agent. And that captain agent, yes, like any scheduler, may thrash if too much is sent its way, but this is a generally difficult problem, right?

I guess I'm saying that I wouldn't expect @aaron-mininger-cic 's solution to fail in unique ways compared to other solutions.