Version 9 (modified by sinziana.mazilu, 14 years ago) (diff)


<< Home

Introduction of event processing threads

The question is now where the event processing threads should be introduced.

First idea

The first idea was to dynamically split the map into several independent regions. The events coming from independent regions should be introduced in different event queues. When we extract the event, the corresponding thread should to the processing.

This idea could not be applied because at certain moments GPS and Cleanup events are generated and we cannot put these events in different queues. This is not possible because for these events we cannot determine their location.
The event Send and Receive have a sender and a receiver and the sender or receiver has a location. The GPS and Cleanup events are not linked to a source or destination location.
The list with vehicles is iterated and for every vehicle we process the event. Furthermore the event queue should be managed by a master thread because the small different event queues would require too much synchronization.

Second idea

The second idea was to use only one event queue, but every event to have a reference to a different processing thread. When we add an event to the queue, we attach a processing thread, and when we extract the event for processing, we wake up the corresponding thread to do the actual processing.

This idea could work, but the next idea is simpler and does not require the change of implementation of the Event class to introduce the reference to a thread.

Third idea

In the method step() we extract an event from the queue (Event e = (Event) eventQueue.get(0);)

If the event is to be processed at the current time (if (e.getTime() == crtTime) ) we call playEvent() to actually process the event.

Only send and receive events have references to objects like sender and receiver and these objects provide the means to find the source or destination location of the event.

The idea is to find the type of event in the step method after getting the event from queue and then interrogating the type of event. For the events GPS and Cleanup we let the main thread to do the work. For the send and receive events we find the location (latitude and longitude). The field sender in the event provides the road index from the global array of roads. Then we have the information required to find all the points on the road and the point index provides the specific point, the location of the event.

The next step is to find the closest intersection to the event. Every intersection has a thread assigned to do the event processing. A future work requires a better load balancing for work processing and the creation of a proper number of threads, matching the architecture and the power of the physical processor.

We have a vector of threads and the index of the closest intersection becomes the index of the processing thread. The thread calls the playEvent() method like the main thread did before.

Final implementation

We chose to implement the best idea from those 3: a work-pool for each intersection.

  1. A thread-pool with executors is created:

public ExecutorService? executor[];

  1. Each intersection will be assigned to a single executor (each executor will be a single thread):


executor=new ExecutorService?[numThreads];

for(int i=0;i<numThreads;i++){

executor[i] = Executors.newFixedThreadPool(1);


  1. Find the index of the closest intersection on the same road for the car.
  1. Assign the event to the thread of intersection

Notice: Because of testing issues (we won't have as mush processors as intersections on a simulation machine), and because fep has 8 processors, we decided to to limit the number of threads for all intersections (7 processors), the 8th one being assigned for GPS and Clear Events. Each event will be computed by the 'NoIntersection? % 7' thread.