Hi, the easiest solution would be to simply change init to return a connection. This breaks backwards compatibility but I don't know whether anyone ever used the return value of init anyway. What do you think?
Best regards, Michael Am 16.03.2016 um 16:22 schrieb Lockhart, Thomas G (398I): > Works fine for me for the simple case of a single connection. > > Glancing at the code, I’m wondering if the gap between making a physical > connection and setting the _connections array, and then looking up the > connection afterwards to return in the connect() method, might be a problem > in multi-threaded code. Could the connection be made instead without losing > contact with the parameters in between? Perhaps just by using the explicit > connection label to look up the connection? > > - Tom > >> On Mar 15, 2016, at 11:27 PM, Michael Behrisch >> <[email protected]> wrote: >> >> 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
