none
Custom CCR Extensions to Guarantee FIFO Task Processing Across All Ports in a PortSet

    Question

  • I just learned (the hard way) that FIFO Task scheduling is only guarantee on a per-port basis in a PortSet and not across all ports inside of that portset. In my case, switching from a portset to a port was not a huge deal, so no harm, no foul.

    That said, FIFO Task scheduling on a per-portset basis seems like a generally useful thing. Has someone already created the neccessary CCR extensions to do such a thing? What are all the steps needed to support such functionality? I imagine I'd have to create a custom PortSet class but I'm not sure if I'd also need a custom DispatcherQueue as well.

    Now, I realize that there are some inherent dangers to the FIFO processing of messages on an entire PortSet. Namely, if you had something like FIFOPortSet<string,int,double> but there were no receivers for a message of type double then the entire port would essentially stop as soon as somone posted a double to the port (though maybe that itself could be a feature in some cases). Still, given that as a danger of this approach, I think having such a tool at my disposal would be great.

    So, does anyone know what is needed to extended the CCR to support this? Further, does anyone have any design ideas or gotchas I should know about before starting?

    Wednesday, February 08, 2012 3:48 AM

Answers

  • One in-built way to do this, at the cost of some runtime overhead, is to create the PortSet with PortSetMode.SharedPort. Underneath, such PortSets are backed by a single Port<object>. Producers can then post as normal but the receiver must listen on the Port's SharedPort property and must do the type-testing themselves.

    • Proposed as answer by gunnnModerator Friday, February 17, 2012 10:25 PM
    • Marked as answer by Kobe1815 Wednesday, February 29, 2012 9:11 PM
    Friday, February 17, 2012 10:25 PM
    Moderator

All replies

  • One in-built way to do this, at the cost of some runtime overhead, is to create the PortSet with PortSetMode.SharedPort. Underneath, such PortSets are backed by a single Port<object>. Producers can then post as normal but the receiver must listen on the Port's SharedPort property and must do the type-testing themselves.

    • Proposed as answer by gunnnModerator Friday, February 17, 2012 10:25 PM
    • Marked as answer by Kobe1815 Wednesday, February 29, 2012 9:11 PM
    Friday, February 17, 2012 10:25 PM
    Moderator
  • Thanks gunnn, that was a very helpful response.

    When I went to implement this approach though, I ran into this problem:

    http://social.msdn.microsoft.com/Forums/en-US/roboticsccr/thread/c39268f7-e639-4210-80c2-a21270db9306

    Where the messages posted to a Port<object> are handled strangely when using predicates to do the casting from object to the appropriate type.

    User beware!

    Friday, March 09, 2012 3:07 PM