The RTSJ is a specification. You really need to enquire whether any RTSJ implementations have made their source code available. The simple answer is no. None of the three certified RTSJ implementations (the Reference Implementation from Timesys, IBM's product and Sun's Java RTS) have their source code generally available.
There have been a number of experimental/partial RTSJ implementations (non-official) like OVM, Flex and jRate that do have source code available.
What aspects of async event handling and ATC are you interested in? I might be able to discuss them without resorting to source code.
Actually I wanted to know how does Async Event Handling could be implemented.
I am confused on few things.
1. In embedded systems we have endless loop that executes all the time, so we have single thread of execution.
2. Then, how does the thread gets notified about the event occurance, if it is in an infinite loop occupying the processor.
3. After receiving the event, does it suspend the current execution and execute the handler, or it starts a new thread to execute the handler.
"embedded system" covers an awful lot of ground these days. If you are talking about very small systems that don't have native thread support then any JVM (real-time or otherwise) that runs on it must provide its own threading implementation. This is not that difficult (see for example the initial implementation of OVM http://ovmj.org - and the original JDK "green threads" implementation . So the JVM is required to support threading.
AsyncEvents are either fired by something inside your application - by calling fire() - or by associating them with something that can occur outside the VM (a "happening" or a POSIX signal). A particular JVM implementation defines what "happenings" it supports. So for example, if your system had an attached device that generated an interrupt when it needed servicing, then a JVM for that system (custom made of course) might expose that as a "happening" with which an AsyncEvent can be associated and so when the interrupt occurs the system fires the event.
Now when an event is fired all AsyncEventHandlers associated with it are eligible for release (ignoring MIT requirements for sporadics). In the simplest model every AEH has an associated thread, which blocks in between releases on some kind of synchronization object - when the AEH is released its thread is woken up and will be scheduled based on its priority. Now un-bound AEH are supposed to be lighter-weight than threads so a thread-per-handler is not a good model from a resource usage perspective. In that case you can use more sophisticated thread-pools to execute AEH.
1. Does the event handler execute on the thread that receives that event or a new thread is created to execute the handler ?
I mean, my doubt is suppose we have a main function that adds event handler to handle the event and then enters infinite loop. Now when the event occurs, the main function suspends execution and the handler runs. Does the handler run on the same stack as the main function's thread or it creates a new thread to execute itself.
If it runs on the stack of main function, how does the main function get suspended and then allow the handler to execute. This is kind of confusing me.
Could you please let me know how does this whole thing work ?
I just read this somewhere on the internet and its confusing me a lot.
'With the resumption model, a communication request results in the interruption of the receiver�s thread of control, and execution of a handler that is supplied as part of the receiver�s logic. The handler runs on the receiver�s stack and consumes the receiver�s execution time budget. When the handler finishes, the receiver continues executing from the point where it was interrupted. The resumption model is supported using signals and signal handling. Asynchrony provided through Resumption Model is called Asynchronous Event Handling'.
I have coded in C# and never seen something like this. Also, it looks like ovmj.rog is down.
I think you are confusing RTSJ "events" and operating system level "interrupts" or "signals".
An AsyncEvent in the RTSJ is just an object that can have other objects, called AsyncEventHandlers, associated with it. When the AsyncEvent is fired then the handlers are scheduled for release. The handlers execute on a thread of control independent of any thread created by the application.
The general term "asynchronous event handling" is very broad. The quote you gave concerns interrupts/signals - the asynchronous event handling mechanism of the operating system. If a thread (native thread not Java thread) receives a signal then it branches to the signal handling routine, executes that code and then returns to where it was - hence the "resumption" part of the description. To understand how this works in detail you'll need to read up on operating system design and implementation. Hardware interrupts are easier to understand - after execution each instruction the CPU looks to see if any interrupt lines are asserted; if they are then instead of executing the next instruction it loads a code address from a an interrupt vector table (based on the number/identifier of the interrupt that was asserted; that code is an interrupt service routine and it does whatever needs to be done, then when it returns the CPU continues executing from the next instruction. Of course it has to save the local state (registers, flags etc) when branching to the ISR and restores it upon return.
To give an example in the context of the RTSJ, the RTSJ allows you to associate AsyncEventHandlers to be released when a POSIX signal occurs - using the POSIXSignalHandler class. So in this example an external entity (maybe a human at a keyboard) would generate the signal to be sent to the VMs process. The VM would have a thread dedicated to receiving those signals - it might using one of the synchronous signal-catching mechanisms such as sigwait/sigwaitinfo. In response to the signal the thread would then cause the associated AsyncEventHandler to be released for execution - which would occur in a different Java thread.
Hope this clarifies things.
PS. google for OVM and Purdue University and you should find another route to it.
So essentially this means that there is dedicated thread that looks for 'happenings' and it is independent of the control loop of the embedded system. So, it would eventually run on its on stack rather then the stack of the control loop thread.
Also, does it mean that the event handler thead only executes when the happening occurs, at other times it would just be suspended and not active doing any kind of computation?
There may be a dedicated thread that "looks for happenings" that all depends on the implementation. And every thread has its own stack - part of the definition of being a thread. But you are also crossing boundaries here between Java threads and native threads - which depends on the VM and underlying OS (if any).
Typically an "event handler" thread would block on a synchronization object (eg Java monitor, or OS condition variable) until informed that there is work for it to do. But again this is an implementation detail. Sometimes these kinds of threads have to do polling - they "sleep" for a period of time, wake up to see if any "events" have been signalled, and if not go back to sleep again.
There are layers in these systems:
RTSJ -> VM -> OS -> H/W
and you can't explain the interactions in detail without knowing how all of the levels operate. You keep mentioning a "control loop" from which I presume you have a simple execution model on the bare h/w, but that model needs a VM on it before you can understand how the RTSJ features work.