MDD_socketCANRead not in compliance with MLS about modelica_devicedrivers HOT 12 CLOSED

The one big drawback with the solution of using ModelicaAllocateString is that using it like that is potentially harmful for any real-time task.

A typical implementation of ModelicaAllocateString could return a memory which is checked by a garbage collector. Since ModelicaAllocateString would be called at every sample period there will be more and more memory allocation as long as the application is running. This means that the garbage collector can kick in any time and slow down the application arbitrarily.

The current implementation returns memory of an external object and hence moves the memory management into the responsibility of the external object. Technically, that seems to me clean solution which is superior when it comes to real-time performance. I see the main use case of this library in soft real-time applications and I wouldn't like to do any thing that potentially deteriorates real-time performance (I want to keep latencies as deterministic as possible)! The only flaw that I can see is that it is not 100% to the letter of the specification (and the specification authors might just not have considered that external object memory can be safely used for returning strings).

Are there any technical reasons in SimulationX (or in other tools that you know of) that make the current approach a no-go?

from modelica_devicedrivers.

Hm, did you see my PR #80? This adds ModelicaAllocateString to the Read functions but they are no longer called. Instead a new set of ReadP (and also WritePfunctions) are introduced that work on the allocated memory of the underlying SerialPackager data buffer. Thus we have the Modelica compatibilty on the old (now obsolete functions) and the performance improvement in the new functions since buffers are local to the external objects only which avoids the memcpy. There is one exception though here that getSting was changed to also work on ModelicaAllocateString.

from modelica_devicedrivers.

I think I understand your motivation. You actually do not want to have the raw data buffers as char* in the Modelica simulation environment. And you actually do not need them. You actually only need the pointer of the buffer which then is immediately passed back to the external C code. Thus, you are right indeed there is no need for ModelicaAllocateString here.

But, yeah, we are lucky. There already is a concept of void* pointers in the MLS for the external C code API - external objects. That's the direction we sould go and I already did in #80. And we get an performance improvement as well since there are now less calls to memcpy. The old API functions are left there for compatibility - but adapted to ModelicaAllocateString. I did not touch the test cases though. But the old API functions are obsolete anyway as only the new API functions are called from the communication blocks.

Going to merge #80 soon since I have more (conflicting) commits to pe pushed in the hold.

from modelica_devicedrivers.

OK, seemed I missed some details regarding #80. Thanks for the explanation. It is a big patch and the impacts of it are currently not obvious to me. I just checked out #80 and I get an error when executing the UDP or SharedMemory examples with Dymola on Linux. Trying to understand why...

from modelica_devicedrivers.

Indeed it is a large change to the sources that was not done during the lunch break.

Thanks for testing. Will also need to check it again.

from modelica_devicedrivers.

Confirmed. Wait, I need to fix some issues with the encapsulation.

from modelica_devicedrivers.

Please check if b44dd84 and 0292b6a and 01c2300 also solve the problems for you.

from modelica_devicedrivers.

Thanks. How to merge that. Do I need to "cherrypick" and if so how? At which branch did this commit go to?

from modelica_devicedrivers.

Ok. Think I got it.

from modelica_devicedrivers.

Same branch in my fork: fix-buf

There still is one issue with finding winmm.lib:

Compiling and linking the model (Visual C++). 

Setting environment for using Microsoft Visual Studio 2010 x86 tools.
dsmodel.c
Z:\Modelica_DeviceDrivers\Modelica_DeviceDrivers\Resources\Include\MDDRealtimeSynchronize.h(186) : warning C4013: 'timeBeginPeriod' undefined; assuming extern returning int
Z:\Modelica_DeviceDrivers\Modelica_DeviceDrivers\Resources\Include\MDDRealtimeSynchronize.h(195) : warning C4013: 'timeEndPeriod' undefined; assuming extern returning int
LINK : dymosim.exe not found or not built by the last incremental link; performing full link
   Creating library dymosim.lib and object dymosim.exp
LINK : warning LNK4199: /DELAYLOAD:pthread.dll ignored; no imports found from pthread.dll
LINK : warning LNK4199: /DELAYLOAD:rt.dll ignored; no imports found from rt.dll
dsmodel.obj : error LNK2019: unresolved external symbol _timeBeginPeriod referenced in function _MDD_realtimeSynchronizeConstructor
dsmodel.obj : error LNK2019: unresolved external symbol _timeEndPeriod referenced in function _MDD_realtimeSynchronizeDestructor
dymosim.exe : fatal error LNK1120: 2 unresolved externals

Error generating Dymosim. 

from modelica_devicedrivers.

Strange. But at least I can now confirm that it now works using Dymola on Linux

from modelica_devicedrivers.

Thanks. Compilation is fixed again by 4012217.

from modelica_devicedrivers.