Hi, I did a first shot on this one yesterday and I am quite happy with the result so far. We now have instances of connections and instances of domains (vehicle, edge, ...) which are mainly needed because they can refer to a connection when the call is made which they can hide as a member. So it is now possible to do either traci.init(...) and continue with the usual traci.vehicle... stuff or you call conn = traci.connect(...) and do conn.vehicle... Everything integrates much nicer now with the parameter and subscription API as well. The tests already run well except for the subscriptions (and I think it is only a problem with the default parameters here).
I only did single instance testing so far, so if you have time to spend on this one please test extensively (also the old API with switch). Best regards, Michael Am 07.01.2016 um 08:40 schrieb Jakob Erdmann: > Great. I've made this into a ticket ( > http://sumo.dlr.de/trac.wsgi/ticket/2091) and will let you know when we > start with the implementation after discussing with my colleagues. > > 2016-01-07 7:19 GMT+01:00 Lockhart, Thomas G (398I) < > [email protected]>: > >> 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 > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ sumo-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sumo-user
