On Wed, Jan 30, 2013 at 1:10 PM, Nilay <ni...@cs.wisc.edu> wrote: > > I had incorrectly understood the code. You can forget about this. But one > thing to note is that, not one but two events are scheduled by the link. > One for to simulate the link's delay and one for simulating the bandwidth. >
OK... I don't follow you; can you please elaborate on the two events? > I am trying to parallelize a simulation which has two systems connected by > an ethernet link. As of now, the sender calls a function in the link to > transfer the packet, and some time later the link calls a function in the > receiver for transferring the packet. In a parallelized simulation, assume > that we have three threads, one thread each for the two systems and one > for the link and each thread has its event queue. When the sender thread > wants to send a packet, it would call a function in the link object which > is owned by the thread for the link. It is possible that the two threads > might end up changing the state of the link concurrently. > > I can think of following ways to avoid this concurrent access to the link > -- > * An event is scheduled by the sender for the link on the link's event > queue. > > * Have a queue between the sender and link. The queue would be protected > by a lock, so that the sender and the link threads do not access it > concurrently. > > * The link object does not have a thread associated to it at all. Instead, > it can schedule events on the queues of the systems associated with its > two ends. When one system wants to send a packet to the other, it invokes > a function in the link object which schedules an event in the other > system. > > As of now, I am leaning towards this final way that I suggested. But it > seems that the two events that I mentioned way above would need to be > fused in to one. > > I am hoping that my description is lucid enough. The final way you mention is indeed how we had envisioned it working. Most objects only belong to one event queue, so they work the same as always, with the restriction that two of these "simple" objects can only be connected directly to one another if they share the same event queue. Some "special" objects are able to bridge between event queues (i.e., threads), and do so by having multiple connections to objects that don't all necessarily share the same event queue. The ethernet link object would be the first of these special objects. No third thread/event queue is needed, the link object can schedule events on either of the two event queues associated with the objects on either end (any of the multiple event queues in the more general case, such as a bus, where you don't have only two connections). So now all of the inter-thread communication is encapsulated in the link object; basically when it gets called by the sender to send a packet, from an event running on the sender's thread, it now has to be able to schedule an event on the event queue associated with the receiver, which is owned by the receiver's thread. Rather than having some sort of locking on the event queue (which would require the owning thread to use locked accesses to the queue, even though the vast majority of the time it will be the only thread accessing that queue), we had talked about having a secondary queue, controlled by locks, where non-owner threads could queue up events they wanted to enqueue on a particular even queue. Then the owner thread would periodically check this secondary queue (probably as part of the regular synchronization operations it's going to need to do anyway to keep from running too far ahead), and during those periodic checks it would acquire the secondary queue lock (if necessary) and move the events from that secondary queue to its "real" event queue. This is the direction we were headed, but I do not recall exactly how far I got in terms of coding that up in the patch that you are working from. So there may be some vestiges of that model already in there. Does that make sense? Steve _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
