[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

280.0. "MCC and CMA" by CLUSTA::PRIESTLEY () Thu Aug 23 1990 20:46

In DECtp we have developed a prototype using Rdb as the storage for our
instance data. On the agent side we use CMA as our threads package and IPC for 
communication. We use the MCC callable interface to manipulate instance data 
once it has been retrieved from Rdb or received via IPC from the MCC access 
module. This has all worked together with no problems. For the second phase of 
our prototype we decided to use the MCC MIR to store the instance data. When we 
try to use the callable MCC routines to access the MIR from the agent side we   
get the following error messages:

%CMA-F-EXCCOP, Exception raised, VMS condition code follows
-CMA-F-NOTCMASTACK, The current stack was not allocated by CMA.
%CMA-F-EXCCOP, Exception raised, VMS condition code follows
-CMA-F-NOTCMASTACK, The current stack was not allocated by CMA.
%CMA-F-EXCCOP, Exception raised, VMS condition code follows
-CMA-F-NOTCMASTACK, The current stack was not allocated by CMA.
%MCC-E-WRONGNUMARGS, Wrong number of arguments

From reading the CMA documentation this error caused by CMA running into a 
"Foreign stack", one which CMA did not create. What I think is happening is 
when the MIR routine is called the routine is creating a MCC thread with its 
own stack and when CMA execute it find itself with this unknown stack. Have I 
got this right? Is there any way around this?

Thanks,

Bill Priestley

BTW, I work with Phil Tamer and Yah-Kong Yang.

T.R Title User Personal
Name Date Lines

280.1 MCC and CMA development race condition PETE::BURGESS Sat Aug 25 1990 01:08 38

T.R	Title	User	Personal Name	Date	Lines
280.1	MCC and CMA development race condition	PETE::BURGESS		`Sat Aug 25 1990 01:08`	38
	> From reading the CMA documentation this error caused by CMA running into a > "Foreign stack", one which CMA did not create. What I think is happening is > when the MIR routine is called the routine is creating a MCC thread with its > own stack and when CMA execute it find itself with this unknown stack. Have I > got this right? Is there any way around this? > The current thread package used in MCC v1.0 and v1.1 can not mixed with CMA in the same process: they are both two user mode library packages, each of which assumes absolute control of thread stack space, thread scheduling, AST handling, etc. NOTE: whenever callable-mcc is used in a process, then mcc thread package creates a scheduler thread during a lib$initialize routine even before your MAIN routine is entered. RMS i/o, SYS$QIOW vectors are patched to revector to mcc i/o routines to issue the i/o request, block the thread, resume the highest priority ready-thread etc... The point to remember here is that once your executable image is linked with "callable mcc" then its execution immediately and unconditionally uses multiple threads. The good news is that we are currently changing MCC to use CMA for both the VMS and Ultrix platform. The work entails providing some jacketted routines over cma to preserve the current srm interfaces and making the rest of mcc "thread-safe". New development (and MCC development) will be encouraged to use cma routines directly rather than the use the jacketted framework routines which will move into obsolence someday. (And the cma interface is likely to be changed a bit after the posix balloting...) An alternative today (albiet with some risk and future conversion work) is to use the "cma compatable (version fall 1989) framework routines" which were not included into the srm because of we want developers to use cma (but since it's not available yet and real work must get done...) The routines for cma-like condition variables, mutexes, once, and thread context handling are accessable in the mcc_kernel_shr. If you need these functions before "mcc with cma" is available for prototyping work, etc and understand their unsupported status, then I can provide the routine documentation. Pete Burgess

> From reading the CMA documentation this error caused by CMA running into a 
> "Foreign stack", one which CMA did not create. What I think is happening is 
> when the MIR routine is called the routine is creating a MCC thread with its 
> own stack and when CMA execute it find itself with this unknown stack. Have I 
> got this right? Is there any way around this?
> 

The current thread package used in MCC v1.0 and v1.1 can not mixed
with CMA in the same process:  they are both two user mode library packages,
each of which assumes absolute control of thread stack space, thread scheduling,
AST handling, etc.   NOTE:  whenever callable-mcc is used in a process,
then mcc thread package creates a scheduler thread during a lib$initialize routine
even before your MAIN routine is entered.  RMS i/o, SYS$QIOW vectors
are patched to revector to mcc i/o routines to issue the i/o request,
block the thread, resume the highest priority ready-thread etc...  The 
point to remember here is that once your executable image is linked with
"callable mcc" then its execution immediately and unconditionally uses
multiple threads.


The good news is that we are currently changing MCC to use CMA for both
the VMS and Ultrix platform.  The work entails providing some jacketted
routines over cma to preserve the current srm interfaces and making
the rest of mcc "thread-safe".   New development (and MCC development) will be encouraged
to use cma routines directly rather than the use the jacketted framework routines
which will move into obsolence someday.   (And the cma interface is 
likely to be changed a bit after the posix balloting...)

An alternative today (albiet with some risk and future conversion work) is to use the
"cma compatable (version fall 1989) framework routines" which 
were not included into the srm because of we want developers to use cma
(but since it's not available yet and real work must get done...)
The routines for cma-like condition variables, mutexes, once, and thread context handling
are accessable in the mcc_kernel_shr.  If you need these functions before
"mcc with cma" is available for prototyping work, etc and understand their
unsupported status, then I can provide the routine documentation.

Pete Burgess