Hi Jakob

Thank you for your response


*"As far as I can tell you are starting a single sumo simulation and are
trying to use it from multiple threads."*

Maybe the example is not as simple as I wanted. I'm actually doing this. I
open a simulation then I create two threads that start their own simulation
(signalized by the "env.reset(execution_name)" command).

*"The traci operations are not thread safe. This is what works*
*- starting a different sumo simulation for each thread and using them as
described in
https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#controlling_parallel_simulations_from_the_same_traci_script
<https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#controlling_parallel_simulations_from_the_same_traci_script>"*

I'm already doing this. I give them labels (with a unique execution_name)

*"- using your own synchronization so that only one thread is talking to
sumo at the same time"*

I used it around the start command. After starting, they should be
thread-safe, since I'm using the labels with getConnection(), right? Or do
I need to add synchronization for every use?



Sincerely,

Marcelo d'Almeida


On Mon, Apr 26, 2021 at 7:00 AM Jakob Erdmann <[email protected]> wrote:

> As far as I can tell you are starting a single sumo simulation and are
> trying to use it from multiple threads.
> The traci operations are not thread safe. This is what works
> - starting a different sumo simulation for each thread and using them as
> described in
> https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#controlling_parallel_simulations_from_the_same_traci_script
> - using your own synchronization so that only one thread is talking to
> sumo at the same time
>
> regards,
> Jakob
>
> Am So., 25. Apr. 2021 um 22:46 Uhr schrieb Marcelo Andrade Rodrigues D
> Almeida <[email protected]>:
>
>> Hi everyone
>>
>> I'm having trouble using multiple simulations in different threads
>>
>> The difference can be perceived by changing max_workers to 1 and 2.
>> "        with ThreadPoolExecutor(max_workers=len(possible_actions)) as
>> executor:" (planning_only_agent.py, line 100)
>>
>> [See attached example (a very simplified version of what I'm actually
>> using)]
>>
>> With max_workers=1, it works just fine.
>>
>> With 2, it gives all sort of errors:
>>
>> "bad char in struct format"
>> "unpack requires a buffer of [x] bytes"
>> A lot of times it just hangs
>> "Received answer 0 for command 211."
>>
>>
>> The easiest way I found to reproduce is to add a breakpoint into a
>> subscribe call and hit continue several times. It is likely to crash when
>> threads stop at the same command, although it occurs eventually without
>> breaking points.
>>
>> Tested in version 1.9.0 (specifically v1_9_0+0210-fa53508669)
>>
>> Thank you in advance
>>
>>
>> Sincerely,
>>
>> Marcelo d'Almeida
>> _______________________________________________
>> sumo-user mailing list
>> [email protected]
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/sumo-user
>>
> _______________________________________________
> sumo-user mailing list
> [email protected]
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/sumo-user
>
_______________________________________________
sumo-user mailing list
[email protected]
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/sumo-user

Reply via email to