Specifying the event ordering of the same PayloadEvent (PLE)

[furuame]

Sparta framework is now good at specifying event ordering against other events. However, if the same event is scheduled twice in the same cycle, the ordering follows FIFO: the one being scheduled earlier is executed first.

// Scheduling events
payload_event.preparePayload(data_a)->schedule(1);
payload_event.preparePayload(data_b)->schedule(1);

// Event with data_a will be executed earlier than the one with data_b.

I ran into a scenario that I need sorta ordering rules to be implemented when the same PLE is scheduled more than once in the same cycle. The ordering rule can be based on the type of the payload. For example, payloads have to be driven following the age order, however they may be always scheduled by the desired order.

I'd like to propose an idea to implement the idea in PLE. When a ordering rule is supplied to a PLE, it's always only a "single" Scheduleable being appended to the Scheduler in a cycle. PLE has to be enhanced with a data structure to stash those payloads scheduled for that cycle. When the Scheduleable is executed by the Scheduler, PLE will drive these payloads at the moment. The idea of implementing ordering is: when a PLE is scheduled, the payload will be appended to the data structure "by the specific ordering" in that cycle.

Any feedback is welcome. My initial thought is adding the ordering algorithm as a template parameter. Those mentioned enhancement will be activated only when a different algorithm is supplied.

[klingaard]

This is an interesting idea and an expansion of the use case of the PLE. I designed/wrote the PLE to deliver as many payloads as a user wants (actually, there's is a limit of 1100 as of this writing) in a given cycle. Granted, this doesn't map to any real hardware construct outside of driving a bunch of wires at the same time, but it sure is convenient!

To do what you want is very tricky. First, the following requirements much be adhered to:

• The PLE allows a user to create multiple payload events and deliver them at different times or the same time
• The PLE is considered "one" event for precedence rules
• The PLE must copy the data provided
• The PLE must be performant and not take significant memory or time for scheduling

How the PLE works:

• The process starts when a user asks the PLE to create a Scheduleable via prepardPayload. This creates a Scheduleable dynamically with the characteristics of the parent PLE (precedence index, etc) and the payload is copied into that object
• The Scheduleable is a reference pointer that can be either scheduled immediately, kept (for later), or just thrown away
• The user calls schedule on the Scheduleable to actually put in on the Scheduler. The reference count is incremented at this time indicating that the Scheduler now owns it
• When the scheduler "executes" that Scheduleable, the payload is delivered and the PLE is notified that the Scedudeable is good for recycling

To make the above change, these are the challenges that need to be addressed:

• If a user creates a bunch of Scheduleables with different payloads, the PLE does not immediately know the "time relation" between these Scheduleables:

   my_payloads_.emplace_back(my_ple_.preparePayload(10));
   my_payloads_.emplace_back(my_ple_.preparePayload(20));
   my_payloads_.emplace_back(my_ple_.preparePayload(30));

• Once the user starts scheduling them, the PLE will need to know these are related, but this isn't easy with the current implementation as the Scheduleables are "independent" to each other:

   for (auto & sched : my_payloads_) {
     sched->schedule(1);  // separate scheduled object
  }

From the above use case, there are a couple of observations:

• The PLE parent knows when a user asked for a Scheduleable
• Each Scheduleable returned contains the payload asked to be delivered
• The PLE does not know how these Scheduleables are associated until they are scheduled (i.e. within the same time)
• To implement ordering between these Scheduleables, an association or ordering alg will be required

From those observations, maybe a good first implementation is to have the Scheduleable maintain all of the payloads to be delivered in the order in which they are either appended or based on a given sorting alg:

   // Order appended == order for delivery
   ple_scheduleable = my_ple_. preparePayload(20));
   ple_scheduleable.appendPayload(10);
   ple_scheduleable.appendPayload(30);

   // Sort the order of delivery
   ple_scheduleable = my_ple_. preparePayload(20));
   auto sort_alg = [] (...) -> bool { // rules };
   ple_scheduleable.appendPayload(10, sort_alg);
   ple_scheduleable.appendPayload(30, sort_alg);

   // Schedule the event
   ple_scheduleable.schedule(1);

Of course this requires that the user of the PLE keep track of the scheduleable associated.

These are my first thoughts. More discussion to be had!

[furuame]

From those observations, maybe a good first implementation is to have the Scheduleable maintain all of the payloads to be delivered in the order in which they are either appended or based on a given sorting alg

That's a good idea. Let's start from this!

[furuame]

// Order appended == order for delivery
ple_scheduleable = my_ple_. prepardPayload(20));
ple_scheduleable.appendPayload(10);
ple_scheduleable.appendPayload(30);
// Sort the order of delivery
ple_scheduleable = my_ple_. prepardPayload(20));
auto sort_alg = [] (...) -> bool { // rules };
ple_scheduleable.appendPayload(10, sort_alg);
ple_scheduleable.appendPayload(30, sort_alg);

After thinking about this thoroughly, yes I agree adding the appendPayload might be the best way to implement this, considering the backward compatibility. But users may have to examine whether there has been a Proxy Scheduleable being scheduled, before they can know which preparePayload or appendPayload to call.

[furuame]

// Order appended == order for delivery
ple_scheduleable = my_ple_. prepardPayload(20));
ple_scheduleable.appendPayload(10);
ple_scheduleable.appendPayload(30);
// Sort the order of delivery
ple_scheduleable = my_ple_. prepardPayload(20));
auto sort_alg = [] (...) -> bool { // rules };
ple_scheduleable.appendPayload(10, sort_alg);
ple_scheduleable.appendPayload(30, sort_alg);

The drawback of this approach is: users have to collect all payloads for appending to Scheduleable before scheduling the PLE. However, not every payload preparing happens at the same place. Payload can be prepared at function A and function B, and they are scheduled in the same cycle!

I intend to make PLE manage things like: knowing which scheduleable to be appended new payloads. So PLE may need to maintain a std::map to know which Scheduleable is mapped to the given cycle.

Function A:
ple_->scheduleWithPayload(payload_a, delay=1)

Function B:
ple_->scheduleWithPayload(payload_b, delay=1)

[klingaard]

Technically the scheduling of the payload is independent of the appending of data to it. So, the order is not important. So, you could to this:

start() {
    // Create an empty payload
    ple_scheduleable_ = my_ple_.createPayload(sort_alg); 

    // Schedule right away
    ple_scheduleable_.schedule(1);
}

funcA() {
   ple_scheduleable_.appendPayload(Adata);
}
    
funcB() {
   ple_scheduleable_.appendPayload(Bdata);
}

[furuame]

I see. So you're preparing a payload (i.e. Scheduleable) in Cycle T+1, by this approach you can append data anytime in Cycle T right? That should work but means users have to maintain the ple_scheduleable_ by themselves, if multiple scheduleables are needed.

Say, in Cycle T, what if users like to prepare payloads for Cycle T+1 and Cycle T+2? Users have to maintain a data structure so they can know which scheduleable to append data. In that scenario, users don't know which scheduleable to append data until they figure when the event would happen. If scheduleable hasn't been created for the cycle, users will need to create one then.

start() {
    // Create empty payloads
    ple_scheduleable_1_ = my_ple_.createPayload(sort_alg);
    ple_scheduleable_2_ = my_ple_.createPayload(sort_alg); 

    // Schedule right away
    ple_scheduleable_1_.schedule(1); // Cycle T+1
    ple_scheduleable_2_.schedule(1); // Cycle T+2
}

funcA() {
   ple_scheduleable_1_.appendPayload(Adata);
}
    
funcB() {
   ple_scheduleable_2_.appendPayload(Bdata);
}