-3

I am passing an array through a message queue:

double data[20];
if(i!=20)
{
    data[i] = getInstance()->real_time_data.f_ChannelData;
    i++;
}
else
{
    i = 0;
    MsgQueueCommunicator::getInstance()->Write_Array_To_Queue(s_hMsgQueue_Communication, data);
}

Write_Array_To_Queue() looks like this:

BOOL MsgQueueCommunicator::Write_Array_To_Queue(HANDLE hq,double data[20])
{
    return WriteMsgQueue(hq,(LPVOID)data, 160,INFINITE,0);
}

Reading from the queue is pretty much the same as writing:

BOOL MsgQueueCommunicator::Read_Buffer_From_Queue(HANDLE hq,double data[20])
{
    DWORD dwBytesRead;
    DWORD dwFlags;
    return ReadMsgQueue(hq, (LPVOID)data, 160, &dwBytesRead, INFINITE, &dwFlags);
}

To initialize the queue on both ends, I use the following function:

HANDLE MsgQueueCommunicator::InitMessageQueue(bool IsRead,wchar16_t* wQueueName)
{
  MSGQUEUEOPTIONS msgopts;
  msgopts.dwSize        = sizeof(MSGQUEUEOPTIONS);   
  msgopts.dwFlags       = MSGQUEUE_ALLOW_BROKEN;//0;
  msgopts.dwMaxMessages = 0;
  msgopts.cbMaxMessage  = 160;   
  msgopts.bReadAccess   = IsRead;   
  HANDLE hq = CreateMsgQueue(wQueueName, &msgopts);
  return hq;
}

The issue i am getting is that the last 3 values of the array will occasionally be 0. I checked by printing the values in the array before and after writing to the queue and noticed the discrepancy. I am not sure where the issue is. I've tried changing the number of bytes for the destination buffer, i printed out the number of bytes read to make sure it was correct, and I have not yet been able to find the root cause.

Here is a snippet of what i see when i print out the values:

6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088488 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088490 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088490 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088490 PID:7bb0046 TID:6a50052 Channel Data (USB): 0
6088490 PID:7bb0046 TID:6a50052 Channel Data (USB): 0
6088492 PID:7bb0046 TID:6a50052 Channel Data (USB): 0
6088528 PID:7bb0046 TID:6a50052 Bytes Read: 160
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088528 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088530 PID:7bb0046 TID:6a50052 Channel Data (USB): 0
6088530 PID:7bb0046 TID:6a50052 Channel Data (USB): 0
6088530 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Bytes Read: 160
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088568 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088569 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088569 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088570 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088570 PID:7bb0046 TID:6a50052 Channel Data (USB): 0
6088570 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100
6088570 PID:7bb0046 TID:6a50052 Channel Data (USB): 1100

The 0's are not intended, but the 1100's are. Im not sure what I am doing wrong (if any), but is it possible to send arrays over message queues without possible memory issues?

Notes: This is being developed for Platform Builder (WEC7) and VS2008.

Javia1492
  • 862
  • 11
  • 28
  • 1
    The best way to solve it is to watch the memory in the debugger. – CyberGuy Sep 09 '15 at 20:54
  • VS2008? any specific reason for that ancient IDE? – Marcus Müller Sep 09 '15 at 20:55
  • @MarcusMüller It is the only version of VS that is supported by Windows Embedded Compact 7 for the project i am working on (which was started almost 3 years ago when Compact 7 was the latest). – Javia1492 Sep 09 '15 at 20:57
  • @Javia1492 Efforts required to ask includes debugging efforts seriously. Provide a MCVE reproducing your problem please! – πάντα ῥεῖ Sep 09 '15 at 21:01
  • You're probably writing out of bounds of an array somewhere – M.M Sep 09 '15 at 21:04
  • @πάνταῥεῖ It would be tough to provide an MVCE because this code is for an IPC. I wouldnt be able to reduce the code for creating the processes. Likewise, most people dont have WEC7 to even be able to recreate this issue. Im not asking to debug the issue directly, but more on a theoretical sense in that how safe is it to send an array over a message queue, and on a basic level have i setup the process to work with queues correctly. – Javia1492 Sep 09 '15 at 21:05
  • @M.M I have a loop variable that is set to the size of the array so that i cannot access out of bound elements. Also, when writing/reading the array from the queue, i specify 160 bytes, which is the exact size of the a `double array[20]`, so writing/reading should not go out of bounds either. – Javia1492 Sep 09 '15 at 21:09
  • use `sizeof` instead of magic numbers in your code. The bug is probably in code you didn't show. – M.M Sep 09 '15 at 21:12

1 Answers1

0

That looks like a timing problem in inter-process communication. A read succeeds but with fewer characters than were sent, because of the relative timing.
You need to check for a short read and retry to complete the desired amount.

JSF
  • 5,281
  • 1
  • 13
  • 20