Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.
 

Timing issues


#1

Hi,

I am experiencing severe timing problems when using SmartInspect logging to a file and via tcp at the same time:

There is a background thread that reads data from the serial port writes them to a global variable that is protected with a mutex. After setting the variable, I have added some timing code that is supposed to tell me wether there are any timing issues. The thread receives a message 30 times a second.

The code looks like this:

var
  UpdateDiff: Int64;
  ThisUpdate: Int64;
begin
  FCritSect.Enter;
  try
    QueryPerformanceCounter(ThisUpdate);
    UpdateDiff := ThisUpdate - FLastUpdated;
    FLastUpdated := ThisUpdate;

    // write the received data to the global variable

  finally
    FCritSect.Leave;
  end;

  // any logging is done after the protected code:
  // exiting here prevents the problem

  FLogSession.EnterMethod('SetData');

  FLogSession.LogValue(lvDebug, 'LastUpdated', FLastUpdated);
  FLogSession.LogValue(lvDebug, 'UpdateDiff', UpdateDiff);
  FLogSession.WatchInt64('UpdateDiff', UpdateDiff);

  FLogSession.LeaveMethod('SetData');
end;

Now, what happens is that every 5 seconds the thread seems to freeze for quite a while (more than half a second). At the same time the SmartInspect console updates its display. If I put an exit at the position marked above, the issue goes away.

There are other threads that run in parallel and write to a different SiSession. I haven’t done any timing on them yet.

Am I doing anything wrong here? Or is SmartInspect just not suited for this kind of application?

twm


#2

No answer yet? Is this the wrong place to ask?

twm


#3

Hello twm,

Sorry for the late response. We are currently moving to a new office and things are a bit busy here this month.

To answer your question, the problem here is, as you have already noticed, that when the Console updates its display (currently roughly every 1000 packets), it may currently happen that a sending client is blocked. We are already working (or to be more precise, have already worked) on this issue and are integrating two changes in one of the following releases. On the client side, we add an option for asynchronous logging and the Console side, we have been refactoring the TCP server to change this blocking behavior.

Sorry for the inconveniences. We are working on integrating the changes.


#4

Hi Tobias,

thanks for the answer.

Is there any easy workaround that I could use with the current version? Any hint will be appreciated.

twm


#5

Hello twm,

Currently, the only possible workaround would be not to use the TCP protocol in your case and only log to a file. You can open a log file in the Console while being in use by your application, so there would be no need to stop your application / stop the logging just for viewing the logged data. I know this is not the perfect solution, but we are working on integrating the changes.


#6

Hi Tobias,

When are you going to release these changes? I have delayed using SmartInspect in our time critical app because of this issue, but now I have run into a different problem with our inhouse logging system which is not quite thread safe, so the easiest option would be to switch to SmartInspecct. But that would require this timing issue to be resolved.

twm


#7

Hi,

We originally planned to release this fix with the next major version (3.0). But we decided to integrate a few more features into the next major version, so we will release a intermediate bugfix release for the TCP part in the Console, probably by next week.


#8

Hi Tobias,

Great. Thanks!