If Events are qued in system, does it consume RAM memory if system not able to execute and terminate events?

[PatrikC]

In an aplication where pralell processes generates events for one eventstructure the events are put in a que before being executed and terminated. What is the symptoms on a system if the system is not able to execute the events and the que increases.

It seems as the system i use shows a increasing consumption of RAM memory, could this be one symptom?

[Davidek]

Hi Patrik

That is one possible symptom, yes. A simile would be that you keep putting things(i.e data) into a cupboard(queue) but don't take anything out you will consume more space, no?

Best Regards

David

NISW

[PatrikC]

That seems as a good similie........

Another question is how the eventstructure que is working "in the background".

If there are several eventtypes created, that is they have different references, how does LabVIEW handle the event que in this case.....is it one que per eventtype or are they all in the same que. I understand that ques when looking at function belong to one eventtype, but in the background the que might be only one for all types meaning that they share the same que recource.

//Patrik 

[LV_Pro]

There is a "Get Queue Status" that could be used to see, amoung other things, how many items are in the queue. It could be used to see if the number continuously grows, and if not then you will have to look for other "memory leaks". If it is the queue, then you have to try and determine why your "consumer" can't keep up with your producer.

[PatrikC]

Im not familiar with how to use the "get queue status" function where i need to monitor the queue status of an eventstructure.

I'm guessing that queues are involved in Eventstructures and that it is possible to retrieve that information but how to derive it from the event handle (object reference) is a little beyond me att the moment. 

I am trying to use the Desktop Evaluation toolkit to monitor the memory usage of VI's. By using the configuration to monitor memory allocations i see the Memory Allocations, Memory Free and Memory Resize.......alltough i have not found a good documentation of what the these events mean.

For instance, to observe a memory behaviour over time for one VI, do i have to subtract the memory allocations from Memory Free and for Memory Resize i have to add or subtract the difference of the "old" and "new" value?

Here is an example of one VI's memory allocations

0 15:37:57,662004 BufferOffset.lvclass:BufferOffset_GOOPKernel.vi Memory Resize 11 0 Handle: 0xAF3F6E0; New: 4; Old: 168

1 15:37:57,662006 BufferOffset.lvclass:BufferOffset_GOOPKernel.vi Memory Free 11 0 Handle: 0xE0C6C18; Size: 168

2 15:37:57,662007 BufferOffset.lvclass:BufferOffset_GOOPKernel.vi Memory Free 11 0 Handle: 0xE0C6C0C; Size: 168

3 15:37:57,662020 BufferOffset.lvclass:BufferOffset_GOOPKernel.vi Memory Resize 11 0 Handle: 0xE0C4A78; New: 168; Old: 168

4 15:37:57,662021 BufferOffset.lvclass:BufferOffset_GOOPKernel.vi Memory Resize 11 0 Handle: 0xE0C4A7C; New: 168; Old: 168

5 15:37:57,662023 BufferOffset.lvclass:BufferOffset_GOOPKernel.vi Memory Resize 11 0 Handle: 0xAF3F6E0; New: 168; Old: 4

6 15:37:57,662035 BufferOffset.lvclass:BufferOffset_GOOPKernel.vi Memory Allocate 11 0 Handle: 0xE0C6E3C; Size: 168

7 15:37:57,662036 BufferOffset.lvclass:BufferOffset_GOOPKernel.vi Memory Allocate 11 0 Handle: 0xE0C6E38; Size: 168 

Does this mean that the VI after nr 0 line has reduced its memory allocation by 168 - 4 units (the representation of the unit is also not specified in tool but guessing it is bytes)?

What is the case after the nr 1 line, is the VI holding size 168 Units of memory or has it released 168 Units of memory?

What is the case after the br 6 line, is the VI allocating size 168 Units of memory or has it allocated 168 Units of more memory then before

What i'm looking for i guess is an explanation on how to enterperate the log lines 🙂

//Patrik 

[Davidek]

Hi Patrik

You are on the right track:

Memory Free is releasing "Size" memory for reuse

Memory Allocate is reserving "Size" more memory for use

Memory Resize is release "old" + allocate "new"

Best Regards

David

[PatrikC]

I'll Finish my own thread......

Desktop Analysis toolkit helped me isolate the problem, alltough some more information in how to enterprate the log data might be needed.

Root cause of problem, is as usual, bug in my own code  .

When a lot of parallell event definitions with registred events that are commonly used by several eventstructures it is very important to include the event case that executes and removes the registred event in every eventstructure that have the eventtype included. My code ended up saving events in the queue, hence stacking memory.......

Thanks all for your help.

//P