Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 25 Sep 2013 20:24:00 +0200

Am Mittwoch, 25. September 2013, 06:50:18 schrieb Eric Norum:
> I think that it's not a bug.   It's more a 'least common denominator'
> issue with the assorted platforms on which EPICS runs. My approach
> has been to add a 'pleaseTerminate' event to the device private
> structure then place a check for this event right after the 'wait for
> work' event in the worker thread.  Shutdown requests first set the
> pleaseTerminate event and then the normal check-for-work event.

I am using that approach, too, at least when I (have to) use semaphores 
directly. Whenever possible I use message queues nowadays, and I type 
the messages using a tagged union, just as I would with an algebraic 
datatype in Haskell. So I have

enum msgTag {
	MSG_DO_X,
	MSG_DO_Y,
	/* ... more message types */
};

and the type of messages is

union msg {
	enum msgTag tag;
	/* ... extra data common to all messages */
	struct
		/* ... whatever extra data is needed to do x */
	} do_x;
	struct
		/* ... whatever extra data is needed to do y */
	} do_y;
	/* ... etc */
};

I even write data constructor functions, one for each message type, e.g.

__inline__ msg_do_x(/*...data needed for a message of this type */) {
	/* assign the struct members here */
}

so I cannot forget to initialize a member. On the receiving end I use a 
switch statement. In this way I can offload routine checks to the C type 
checker, which makes the program much more robust against changes such 
as adding a new message type. Which brings me back to the topic at hand, 
since shutdown is now just another message type:

enum msgTag {
	...,
	MSG_SHUTDOWN /* normally needs no extra data */
};

I find it much easier to reason about my code if it is structured in 
this way.

Cheers
Ben

> On Sep 25, 2013, at 6:15 AM, Dirk Zimoch <[email protected]> wrote:
> > Hi folks,
> > 
> > Today I did some tests regarding "clean" shutdown of an IOC and
> > found some unsatisfying results. There seems to be no clean way of
> > destroying events, mutexes, or message queues, because they all
> > cannot be destroyed as long as there are threads waiting on them.
> > At least that is the case on Linux.
> > 
> > Example: One thread is waiting on an event. Whenever it gets
> > signaled, it does some work on hardware.
> > 
> > At exit I have do shutdown the hardware cleanly. After this time no
> > thread must try to use it any more. Also I better don't simply kill
> > the work thread while it is accessing the hardware. (And I probably
> > do not know all the threads involved). So I prefer to terminate
> > while the thread has noting to do, i.e. while it is waiting on the
> > event.
> > 
> > I had expected that when I destroy the queue, all pending threads
> > would wake up and receive an error. This is not the case. Instead I
> > found that destroying the event failed with "Device or resource
> > busy"
> > 
> > The same is true for mutexes as I tested. Also message queues cannot
> > be released like this.
> > 
> > Is this a bug or simply "unsupported"?
> > 
> > Any idea what I can do?
> > 
> > Dirk
-- 
"Make it so they have to reboot after every typo." -- Scott Adams

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System