I had noticed this earlier but not written a solution. I’d be happy to help with a conversion to class-based encapsulation or with testing.
- Tom > On Jan 6, 2016, at 9:45 PM, Matěj Kubička > <[email protected]> wrote: > > If it comes to that I am sure I can find few hours to help with it. The > changes to do are extensive, but they affect only structure, not > functionality. This should simplify both the conversion and testing. > > Matej. > > PS: In this particular case the interpreter lock will not have much of > an effect on performance as the worker threads are mostly in the > suspended state (or at least I think they are). They should either > sleep, or put nonblocking send request, or process response .. they > don't use spinlocks and they don't do any heavy computations. The real > work is done by sumo. > > Anyway, threads are evil :-), see > http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf. If > performance is an issue you can circumvent the interpreter lock by > implementing the time-critical stuff in C/C++ with posix threads. > > > > > On 6.1.2016 08:14, Jakob Erdmann wrote: >> So far we didn't use traci in a multi-threaded application. Rather we >> had a single thread of control due to the rather tight coupling of the >> different simulations. >> I understand the problem for your queue/worker example and I think >> your approach to solving it is straightforward. >> With a global default TraciAdapter it would even be possible to >> maintain full backward compatibility for people that use a single >> instance (which I consider quite important). >> Would you be able to help with converting the remaining traci modules? >> >> regards, >> Jakob >> >> PS: Note, that multi-threading in the default python implementation is >> still not efficient when spending lots of time in python code due to the >> GIL: https://wiki.python.org/moin/GlobalInterpreterLock >> >> >> >> >> 2016-01-06 5:15 GMT+01:00 Matěj Kubička >> <[email protected] >> <mailto:[email protected]>>: >> >> Thanks for the information, I didn't know about this. >> >> The method you describe on the wiki is single resource access >> multiplexing. Why not having traci instance specific to each >> connection? >> >> Consider this setup: I have N worker threads to which I assign >> jobs dynamically from a single queue. The traci.switch() is >> useless within the workers as Python can preempt anytime. >> >> I can call traci.switch() before every call to anything >> traci-related and pack it within some global lock in order to >> ensure proper synchronization. Like this I get 4 statements for >> every single call to traci. This is inelegant, to say the least.. >> >> How do you usually use it? Maybe there is better way for me to >> implement it. >> >> Thanks, >> Matej. >> >> >> On 5.1.2016 08:16, Jakob Erdmann wrote: >>> Hello, >>> As I wrote before it is already possible to run multiple >>> simulations from the same script. I updated the documentation to >>> make this more obvious in the future: >>> >>> http://sumo.dlr.de/wiki/TraCI/Interfacing_TraCI_from_Python#Controlling_parallel_simulations_from_the_same_TraCI_script >>> regards, >>> Jakob >>> >>> 2016-01-05 2:16 GMT+01:00 Matěj Kubička >>> <[email protected] >>> <mailto:[email protected]>>: >>> >>> Hi Jakob (et al.), >>> I needed the same - to run multiple sumo instances in >>> parallel. Unfortunately Python bindings for Traci do not >>> support that since the traci package is written as a state >>> machine. >>> >>> I've worked on it a bit and adapted the traci to support >>> multiple coexistent connections. The changes are extensive, >>> but trivial. I have wrapped the IO-related stuff in a class >>> TraciAdapter, whose constructor is now derived from what >>> originally was traci.init(). Then I wrapped functionality of >>> vehicle and route modules in classes Vehicle and Route and I >>> instantiate them in TraciAdapter's constructor. >>> >>> Except that now you have to access traci objects through >>> instances of TraciAdapter, the interface remains the same >>> otherwise. >>> >>> My experiments are limited to adding a vehicle and to >>> collecting data about it. I worked only on concerned parts of >>> the package. I am sending you the code as mere proof of >>> concept, in case you are interested in such a functionality. >>> >>> Matej. >>> >>> PS: I tried to send you full package, but our mailserver >>> blacklists zipped attachements, so I am sending you the three >>> afffected files only. >>> >>> PS2: simplified example that controls 2 sumo instances, adds >>> a vehicle to each and dumps their speeds as they progress in time >>> >>> import traci >>> >>> tad=traci.TraciAdapter(port) >>> tad.route.add('probe_route', edges) >>> tad.vehicle.add('probe', 'probe_route') >>> >>> tad1=traci.TraciAdapter(port+1) >>> tad1.route.add('probe_route', edges) >>> tad1.vehicle.add('probe', 'probe_route') >>> >>> while(True): >>> tad.simulationStep() >>> tad1.simulationStep() >>> print tad.vehicle.getSpeed('probe'), >>> tad1.vehicle.getSpeed('probe') >>> >>> >>> >>> >>> >>> >>> On 17.12.2015 15:54, Jakob Erdmann wrote: >>> >>> Yes. You can run multiple instances of sumo at the same >>> time. It is even >>> possible to control multiple instances from the same >>> TraCI script as longs >>> as you are careful with the port numbers. >>> regards, >>> Jakob >>> >>> 2015-12-17 14:39 GMT+01:00 Phuong Nguyen >>> <[email protected] >>> <mailto:[email protected]>>: >>> >>> Hi, >>> >>> I'm trying to optimize a traffic scenario using >>> optimization algorithm and >>> sumo. In the optimization process, I need to call >>> sumo to run the scenario >>> simulation so many time. Can a number of the >>> simulations run parallel? >>> >>> Thanks so much. >>> -- >>> Ms. Nguyen Thi Mai Phuong >>> Division of Science Management and International >>> Relations, >>> Department of Network and Communications, >>> Thai Nguyen University of Information and >>> Communication Technology, >>> Thai Nguyen city, Thai Nguyen province, Vietnam. >>> Email:[email protected] >>> <mailto:email%[email protected]> >>> Tel: 0985 18 38 48 >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> sumo-user mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/sumo-user >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> sumo-user mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/sumo-user >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> sumo-user mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/sumo-user >>> >>> >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > sumo-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sumo-user ------------------------------------------------------------------------------ _______________________________________________ sumo-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sumo-user
