Re: [eclipse-clp-users] embedded ECLiPSe in C++, problems with post event

From: Joachim Schimpf <jschimpf_at_...311...>
Date: Tue, 02 Apr 2013 00:13:42 +0100
On 24/03/2013 17:46, Gesche Gierse wrote:
> On 03/22/2013 10:47 PM, Joachim Schimpf wrote:
>> On 22/03/2013 18:47, Gesche Gierse wrote:
>>> Hello,
>>> I'm currently using ECLiPSe embedded in a C++ project and I'm facing
>>> some problem with sending events from C++ to ECLiPSe.
>>> The C++ project has various threads, some running continuous, others
>>> only for some time. The ECLiPSe context is initialized within one of the
>>> continuous threads.
>>> However the ECLiPSe program I want to run needs to call an predicate
>>> whenever the control-thread is running (this is one of the
>>> none-continuous threads). So I post an event to the ECLiPSe context
>>> every time the control-thread is running.
>>> Everything compiles just fine, and for like a minute it will run the way
>>> it should, but at some time I always get a "Bogus event queue
>>> notification in next_posted_event()"-error.
>>> So my question is, is this a threading problem? Does posting events not
>>> work well, when used in a thread that is non-continuous?
>> Yes, this is very likely a threading problem.  The current event posting
>> mechanism is not designed for thread communication.
>> Could you briefly explain a few more details about your architecture,
>> so we can suggest an alternative solution:
>> Does your ECLiPSe thread process jobs that it receives via these events?
>> If yes, are these jobs then queued, or interrupt each other?
>> Is the event simple, or are you passing any data (arguments, etc)
>> along with the event notification?  Or is it just an abort-event?
> The event is quite simple.
> In general the C++ threads belong to a cycle: sense, think, act. Eclipse
> should do the "think" part, so the event I'm passing simply tells
> ECLiPSe, that it's the start of the "think"-phase, and therefore it can
> read the sensor data which are up to date at that point (no arguments
> needs to be passed). It's simply an timing thing.
> I used a solution with event_after_every at first, but I would rather
> like to sync it with the C++ threads.

Sorry for the late reply.

 From what you are saying, I think the most straightforward solution
is to leave all the synchronisation to your C++ code, and letECLiPSe
only execute a single read-compute-write sequence at a time.

So the ECLiPSe code would simply be

main :- read_sensor(Data), compute(Data, Result), write_result(Result).

In addition, you have a "server loop" in C++, like

       wait for next sensor data to be ready;
       status = EC_resume();
       if (status!=EC_succeed)
       read the result;

This loop and the ECLiPSe code are executed by the same thread
(post_goal+resume essentially just calls the ECLiPSe code).
There is no waiting or event handling in ECLiPSe.

-- Joachim
Received on Mon Apr 01 2013 - 23:14:50 CEST

This archive was generated by hypermail 2.2.0 : Mon Jul 09 2018 - 02:05:30 CEST