Hyperion Entertainment Message Boards

Project=Perception-IME
Repository=http://code.google.com/p/perception-ime

Within the Perception/Library/daemon.c file I have two functions am I writing together at this time,
1= ExecInputHandler() /*called from input.device as a Soft-Interrupt*/
2=ProcInputHandler() /*called within the Perception-IME process context*/

And I have a complex data-structure that I am currently needing to share between the two contexts...

I am not interested in using Semaphores as my limited understanding is that Interrupts happen at any time so I can not allocate/free or obtain semaphores as they are all potentials for crashing the OS, however with the upcoming update to SMP awareness, What semantics would be safe to mark access to this data as being "shared" or a design pattern reference in using a data structure from multiple contexts safely?

I'm aware that the Soft-Int context may have that code run at any time, and the process only runs when signalled (possibly even being interrupted when running for the interrupt to execute...)

If this was a device setup I would want to work from an example but I lack information about design patterns that are safe for this work.

Would this be a case where Forbid() and Permit() would actually be good to use? to enable quickly copying the data concerned to work with?

I'm wanting to keep ExecInputHandler() as short as possible without introduction of anything dangerous,
and ProcInputHandler() being on the process context gives me the advantage of separation of the plugins for the IME from the input.device.

each plugin corresponds with a specific Language which has additional Input Modes (Existing languages only have a single input mode "Direct") for example,
Japanese would require multiple Input modes with a mix of "Direct" and "Translated" options.
The "translated" Mode options will require that an external to the IME plugin function be called to obtain a word from an input buffer along with translation candidates.

working up the plugin hook handling is going to be relatively easier than making the completed input handling imho, so I'm focusing on what seems more difficult for now.

As for "display" I have put some UTF8 strings pre-encoded into the Japanese.Language module already,
just GetLocaleStr() any of the 72 valid strings to ask for to receive a correct string to try displaying.

the IME will focus only on Input and nothing display related unless required.

You must not do anything in an interrupt service routine (ISR) that can cause the ISR to be suspended. The ISR is called using the context of the Process that caused the interrupt or (in the case of a hardware interrupt) the Process that was running when the hardware interrupt was serviced, so you must not Obtain() a semaphore whilst inside that ISR.

However, you can send messages to a List at any time. Since they go into a queue, they are quick and won't upset the consumer at the other end. The only caveat is that AddHead/AddTail and RemHead/RemTail are not atomic, and you must be sure not to do that while someone else is manipulating the List (either another Producer or the Consumer at the other end). You can do that with a Forbid/Permit, but you must put Forbid/Permit calls around *every* access to the queue, not just in the ISR.

Also, if you are making up a message to send from the ISR, allocating memory is dicey - the allocation process might have to clean up system memory in order to satisfy your request, which could take a long time. It is better to use a Pool of memory that is more likely to have enough memory spare at random times.

@Tonyw: so Forbid()/Permit() it is then,

I was quite aware of the unstable state of system structures which is why I said of not having interest in semaphores,

I have also skipped any allocation issues in having the process make all of the allocations prior to the InputHandler() registration,

so the data will be into a fixed array of InputTagItem structures.

What I'm unsure about is how to avoid any "race condition"s,

From your message you are saying this is when to use Forbid()/Permit() to properly share access at this time?

Belxjander wrote:so Forbid()/Permit() it is then

No, that is not allowed. Find another way.

ssolie wrote:

Belxjander wrote:so Forbid()/Permit() it is then

No, that is not allowed. Find another way.

Would I be allowed to use Soft-Interrupts as functions and deliberately use them for race avoidance?

Using Cause() applied to an internal only set of Soft-Int Function()s,

My understanding is Hardware Interrupts, Software Interrupts and regular multitasking is the rule of ordering execution context with Interrupts outside standard multitasking and being a kernel headache for housekeeping.

I'll try that as my workaround which then provides a limited mechanism for Soft-Interrupt queue ordering event handling and non-race access to the shared data.

Is there a better way that this? as it is the only way to not introduce deprecated calls or transient errors unrelated to this code that I am aware of.

Belxjander wrote: 1= ExecInputHandler() /*called from input.device as a Soft-Interrupt*/

I am quite sure that an input handler of input.device is not called during an interrupt. IMHO input.device uses an interrupt data structure solely because a struct Hook didn't yet exist in Kickstart 1.3.

I would just use a simple PutMsg to send messages from an input handler.

thomasrapp wrote:

Belxjander wrote: 1= ExecInputHandler() /*called from input.device as a Soft-Interrupt*/

I am quite sure that an input handler of input.device is not called during an interrupt. IMHO input.device uses an interrupt data structure solely because a struct Hook didn't yet exist in Kickstart 1.3.

Yes, it's a simple function call, struct InputEvent *Handler(struct InputEvent*, APTR), newInputEvents = is_Code(inputEvents, interrupt->is_Data), running in the input.device task.
If it would be an interrupt the function arguments would have to be different: uint32 Handler(struct ExceptionContext *, struct ExecBase*, APTR).

Thank you for clarifying that,

As my impression of running as a Soft-Interrupt was wrong, Semaphore blocking would be a valid option in this case,
as both input.device and my own process can share reading and only need very short write-exclusion,
I'll try that and see what the results are.

I'll make notes of Soft-Interrupt calling to avoid a race condition and work on that experiment later.