7 Replies Latest reply on Nov 21, 2012 6:56 PM by davetrollope

    LBM Heartbeat to avoid context switching

    New Member

      Hello,

       

      We'd like to explore options in LBM receiver that creates a spinning effect to avoid excessive context switching. Specifically, I'm wondering if there are attributes related to lbm's heartbeat implementation that could be useful.  What parameters/configurations should I be looking into?

       

      Thanks,

      Peter

        • 1. LBM Heartbeat to avoid context switching
          New Member

          Hi Peter,

           

          UMS (formally LBM) doesn't handle heartbeats any  differently than data, so its not clear why you are focusing on that  specifically - perhaps you could expand on your thoughts there?

           

          Addressing  the issue of context switching is a common concern of application  designers looking for the lowest latency processing of data. The are two  degrees of implementation to address this.

           

          First, the  most common usage of UMS is to have the receiver callback processed on  the thread that manages the socket - this eliminates any context  switching. Context switching only occurs if the application callback  then passes data to another application thread. In this case it is the  application design that is inducing the context switch. However, it is a  performance trade off - if you can do all the application processing in  the receiver callback and keep up with the incoming data rate, you  should. If you can't (or the processing has blocking operations), you  are forced in to some degree of context switching and have to pass data  to another thread for processing - either through an application queue  or an event queue.

           

          Secondly, there is "Sequential  Mode". If you can keep up with the data rate, but don't want all the  code to process data in a callback, you can run the event loop that  processes data on your application thread and then returns to the  application code. To use this mode, you must set the context option  "operational_mode" to sequential, and then have your application call  lbm_context_process_events(). You pass a minimum time to run as an  argument and use lbm_context_unblock() to force a premature return from  this function when needed. Using this model allows you to create an  entirely single threaded application without putting all the processing  inside a receiver callback.

           

          Ultimately though - if your  application can't keep up with the incoming data rate on a single core,  you must accept the overhead of context switching. Also for streaming  sources, you can use a feature called multi-transport threads to  distribute sockets across a thread pool. This ensures single threaded  behaviour for any socket created but utilizing multiple threads.

           

          There are many reasons why the context thread is  scheduled to run - not just heartbeating (otherwise known as TSNI's or  Session Message's) - but on receiving discovery messages (topic  resolution) - if your goal is to reduce the number of times the context  thread is scheduled then all of those configuration options need to be  looked at and a conversation with the support team would be worthwhile.

           

          Cheers

          Dave

          1 of 1 people found this helpful
          • 2. LBM Heartbeat to avoid context switching
            New Member

            Hi Dave,

             

            What would happen if lbm_context_unblock() is called from a callback while in the operational mode is set to "embedded"?

             

            Thanks,

            Dmitri.

            • 3. LBM Heartbeat to avoid context switching
              New Member

              Hi Dmitri,

               

              That's a great question! Embedded mode uses a separate function to implement the main loop, so I think it would not make any difference and the embedded thread would continue - but the only way way to be sure would be to check with the support team if you are concerned about this usage.

               

              Is there a reason you want to potentially use embedded mode and have code that calls unblock ? I'd like to hear the use case around that.

               

              Cheers

              Dave

              • 4. LBM Heartbeat to avoid context switching
                New Member

                Dave,

                 

                The reason is simple - if the behaviour of lbm_context_unblock() is "good" enough, that would allow writing a single callback that would work for both sequential and embedded mode, without having to check which mode the context has been created in. In the sequential mode, the dispatch loop would return to user after the callback when needed, while in the embedded mode it would behave the default way (which makes sense as it is not a user thread that dispatches messages).

                 

                As an example, such a callback may trigger some condition. In the embedded mode, the user still can check the condition and take an action (like "stop the context and exit") from a user thread. In the sequential mode, there may be just one user thread, and there's no chance to check the condition from outside the dispatch loop unless calling ..._unblock().

                 

                - Dmitri.

                 

                P.S. Unfortunately, lbm_context_process_events() only accepts timeout values that are not less than the timer resolution (which is greater than zero). If it could accept zero timeout, it would provide a way to create a single user thread tha does busy wait on both the context and the IPC events.

                • 5. LBM Heartbeat to avoid context switching
                  New Member

                  Hi Dmitri,

                   

                  I've never heard of anyone mixing both sequential and embedded mode in the same process - most folks use one model or the other, but I can see the value in having one context tightly controlled with sequential mode and others being allowed to self manage. In that case I would expect different callbacks to be used because the nature of data being receoved is different (critical vs non critical perhaps).

                   

                  However, taking a closer look, it does seem like the unblock call will cause the embedded thread to exit which I can't imagine is desirable under any circumstance.

                   

                  Your feedback about the parameter handling in process events is interesting.

                   

                  I recommend for both these behaviors you open a support ticket to get deeper assistance.

                   

                  Cheers

                  Dave

                  • 6. LBM Heartbeat to avoid context switching
                    New Member

                    Hi Dave,

                     

                    I didn't mean mixing modes in the same process. I meant writing one callback that would serve both cases withouth having to check which mode the context thread is in.

                     

                    Thanks for the suggestion - I'll probably open a ticket to implement the polling behaviour for lbm_context_process_events().

                     

                    Regards,

                    Dmitri.

                    • 7. LBM Heartbeat to avoid context switching
                      New Member

                      Hi Dmitri,

                       

                      Ah yes - i get it. Sharing code modules (called from callbacks) to handle common data messages in different apps is common, and not being able to always call unblock in that case when different apps use embedded or sequential mode could be quite awkward.

                       

                      Cheers

                      Dave

                      1 of 1 people found this helpful