时间问题？ 程序可以在Visual Studio中正常运行，但不能独立运行

Question

I have a native C++ DLL. The DLL creates a thread which repeatedly reads data from an external device. If data is not read quickly enough, the device can overflow.

The 'read' loop looks something like this:

while (true)
{
    read_from_device();

    buffer_data();

    Sleep(5);  //Allow data to accumulate 
}

I also have a C# application which utilises the above DLL. It calls a function in the DLL to kick off the 'read' thread, and then periodically calls another function in the DLL to check whether all the data has been read from the external device.

Both the application and the DLL are built in 'Debug' mode in Visual Studio (2008 in this case).

If I run the application through Visual Studio everything is fine: data is read from the external device and no overflows occur.

When I run the same application 'standalone' (by directly running the .exe), I encounter overflows.

I think the only difference is that in the first instance the Visual Studio debugger is automatically attached to the application? Bear in mind I have no breakpoints set.

There must be a timing issue present in my application which is somehow rectified when the debugger is attached to it?

How on earth can I go about debugging this problem?

What other differences are there between running an application via Visual Studio and running it directly?

EDIT :

Here is the code in more detail:

int buffer[MAX_EVENTS*2];
int bufferIndex = 0;
int eventsReturned = 0;

BufferObject *pNewBuffer;

while (bPollData)
{
    read_data(buffer[bufferIndex], &eventsReturned);

    bufferIndex += eventsReturned;

    if (bufferIndex >= MAX_EVENTS)
    {
        pNewBuffer = new BufferObject(buffer, bufferIndex);

        myList.AddTail(pNewBuffer);

        bufferIndex = 0;
    }

    Sleep(5);
}

...
... 

class BufferObject {
    int *buffer;
    int bufferSize;
public:
    BufferObject(int* source, int size)
    {
        buffer = new int[size];
        bufferSize = size;
        memcpy(buffer, source, size);
    }
};

Answer 1

   Sleep(5);

Well, that is 99% of your problem right there. You already know that you have a problem when your code runs fast. You artificially slowed it down to put a band-aid on the bug. But of course should not be surprised that it breaks again when you do something else that makes your code run faster. Like not running it with a debugger attached.

You probably don't even know for a fact that 5 is adequate. It is a pretty random number and the amount of time your program will actually sleep is very rarely exactly 5 milliseconds. Default sleep accuracy is 15.625 msec but that can change when another program calls timeBeginPeriod(). Just running a browser is enough, Chrome notoriously changes the interrupt rate. So instead of 15 msec you suddenly run 3 times faster. Breaking your program. You don't want Chrome to break your program ;)

You have to tackle the real problem. Which surely is something like you just taking however many bytes the device sent you and putting it in a BufferObject. So if your program runs fast, you get many buffer objects, each with but a little bit of data. That can cause havoc on whatever code that consumes the data. A traditional problem is the UI of the program going catatonic, madly trying to keep up with the required repaints.

Without nearly enough insight from the question, a random guess is that you must buffer the device response first until it accumulated enough bytes to make it worthwhile to stick it in a BufferObject. If you continue with the Sleep() band-aid then pick a sleep amount that's an integer multiple of 15.625 rounded down. Like 15, 31, 46.

Answer 2

You're likely suffering from lack of synchronisation between the thread that is collecting the data (and building the list of buffers) and the thread that the application uses to access (and presumably remove) the buffers.

You likely need to include some locking around access to the buffer list. It seems that you have an "active" buffer which only the data reader thread can write into (buffer) and when this is full you copy this data into a new buffer object and add it to the list. You should likely lock around the use of the list (the list may include correct synchronisation internally but it's unclear from your code example).

There appears to be no way for the loop to inform the read_data() function of the remaining space in the buffer it passes in, this may be a cause of memory overruns which could be causing problems.

Personally, since you're dynamically allocating buffer objects anyway, I'd skip the memory copy entirely and simply hold an active buffer object and read into that directly rather than into a temporary buffer which you then copy into a buffer object.

It's impossible to do more than guess given the nature of the question and the lack of code.