|
As far as the framework environment is concerned, "callable MCC"
and "regular MCC" are the same- same shareable images, same initialization,
same routines, same control - any differences are layered on top of the
framework by the architecture.
So what's architecture and what's implementation?
You must tread carefully here because implementations will change
while preserving the interfaces. My implementation comments are only
good for v1.0 and v1.1
In the SRM Table. 4.2 summaries certain restrictions (which have a decided VMS bias)
The philosophy expressed is conservative to insure reliability and it's
difficult to say what the consequences will be it you don't follow the guidelines.
>
> - Is it possible to use threads mechanisms, MCC timers, ...
> from the callable interface ( and what has to be done to use them ) ?
>
Yes! With callable MCC developers may invoke *any* of the common routines
specified in the SRM (this is interface stuff not implementation)
> - How far can MCC threads and VMS-specific ASTs, exceptions handlers,...
> coexist ?
>
1. None of the common routines are AST re-entrant, so don't
call any published mcc routines from ast level.
(there are some unsupported rtns for queueing ast event information
to waiting threads)
2. MCC establishes its exception handler which you may preempt (risk=side-
effects of kernel components not cleaning up)
(this part of the framework is initialized early (ie via lib$initialization
prior to the invocation of your main routine; other parts
are initialized when the subfacility is first used -eg locking services.)
I found that VMS exception handlers and exit-handlers aren't all that reliable
anyway (handlers are not called if "forced image exit" occurs due to
stop /id, last chance handler is called, "quit" from the debugger,...)
MCC locks are dequeued via a kernel mode rundown handler.
> - Same question for MCC timers and sys$wait, sys$hyber, sys$wake... calls.
>
Since MCC framework is scheduling threads in user mode,
if your code issues a sys$hiber request, then the process will be
blocked- asts will fire but no other threads can run until your
thread wakes up by what ever mechanism you devised.
The scheduler thread uses sys$hiber when there are no other threads
to run. MCC ast handlers will issue sys$wake when it enqueues a
thread onto an empty ready-to-run queue.
If you are designing new programs, then I recommend that you follow the SRM guidelines,
and anticipate using the CMA threading package. The U*x market is growing much
faster than the VMS market. You may consider designing your application to run
on both VMS and Ultrix, Unix V, OSF, OS-2 (and all the other open systems...)
If you are revising existing code to use MCC on VMS only, then let's
discuss any additional details off-line.
Pete Burgess
|