nathan binkert wrote:
>> I'm not clear on what you're getting at here by using types in C++.
>> The way things currently work right now is that everything that want's
>> to schedule an event needs to schedule it through an event manager
>> (all SimObjects are EventManagers). An event manager is bound to a
>> single event queue and has an internal pointer to that event queue.
>> It's simply a matter of assigning event queues to event managers in
>> the python config. Thus the objects that use a given event manager
>> shouldn't even know how to access the other event queues (unless you
>> give an object a pointer to multiple event managers.)
>>
>>
>> When one object wants to cause something to happen on another object,
>> it usually goes through some sort of Port interface. There's an event
>> buried in there.
>>
>>
I was being unclear. I know :-). I agree that objects should only have
a pointer/reference to their own EventQueues otherwise it would become a
mess. When I talked about the generic safe interface type. I was
thinking about the interface the port should present to the object that
"wants to cause something to happen on another object". So the port is
sort of a gateway to that other object and it would be the port that
generates and schedules the event on the to be affected object's queue
(through the EventManager interface). If all the "affecting" object has
is a pointer to the safe interface you can guarantee that the
interactions between those objects is PDES-safe ( I'm assuming you have
an intuitive understanding of what this means ;-) ). Creating such an
interface which complies with all the restrictions of PDES-safety and
still allows some type checking is far from trivial but I hope to mail
my prototype of the interface soon. Be warned, it might be to strict to
your liking. A trivial interface would have one method
"triggerEvent(Cycles time)". This is as generic as it gets but the
calling object can not know of what type the object it is calling is.
Thus eliminating any type checking. Templates can provide a solution
here. Simple example:
template<class EVENTPARAMETERS>
class SafeInterface {
void triggerEvent(Cycles time, const EventParamaters &p)
};
There are still some PDES-safety problems with these interfaces but I'm
just mentioning it as an illustration.
>> When I said that two collections of SimObjects can safely be simulated in
>> parallel if and only if these collections of objects only interact with each
>> other through events I assumed that causality problems are handled by
>> Eventqueues. To be more precise, if objects in one collection can send
>> events to another collection's EventQueue then this one should not simulate
>> past the time of the EventQueue of the objects who can send those events. In
>> PDES terms this collection of SimObjects would be "state objects" and
>> together with their EventQueue they would form a "process". Just so you
>> have an idea of what I mean with my terminology.
>>
>
> We generally don't actually work this way. When one object wants to
> cause something to happen on another object, it usually goes through
> some sort of Port interface. There's an event buried in there. I
> think it's really up to the port objects to deal with moving things
> from one event queue to another and to manage the timing differences.
> The port interfaces themselves would probably have some sort of
> lockless queue inside to move events from one side to the other
> without requiring locking.
>
>
The fundamental law in PDES is that one process should not run ahead of
another if this one can trigger events effecting it. If an object
schedules an event that should have been processed at time T1 but the
eventqueue is at time T2 with T2 > T1 then you'll have causality errors.
So this is what I meant with blocking eventqueues. Other then that I
agree that concurrent scheduling should be lockless. Why not implement
the eventqueues as a lockless qeueu?
> This could really just be two different ways of looking at the same
> thing, but I think fundamentally, we want to have a long term goal of
> not having locking in the queues and using some lock free data
> structures to move events from one queue to another.
>
>
I think I'm pretty much looking in the same direction as you are.
Thanks for taking the time to write,
Stijn
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
