Conference azur::mcc

    The following are the call arguments.
    
    proc_adr  procedure by reference
    thr_name character-coded text string by descriptor
    thr_priority unsigned 32 by reference
    thr_stksiz unsigned 32 by reference
    thr_id unsigned 32 by reference
    parm1...parmN  unsigned 32 (varying_arg) by reference
    
    

    RE:.0
    
    Pierre,
    
    What you have specified looks okay to me.  We create hundreds of
    thousands of threads (not all at once) during testing, so I feel
    confident that the thread_create routine is working correctly. Could
    you place a response with the declaration of the
    "g_mip_disconnection_thread_id" variable?  Are you sure it is a
    longword (4 bytes)?  I believe the low order two bytes of the thread-id
    are sometimes zero.  Also, it may be possible that another pointer is
    pointing into the variable and that the other pointer is placing two
    zeros in the upper longword (a shot in the dark, I know).  Finally, I
    noticed that the variable is prefixed with a "g_", could this mean that
    this variable is globally shared between concurrently running threads?
    
    -Matt.

Thanks for your help.

Wonderful problem.

Yes g_mip_disconnection_thread_id is a global variable, it is defined
correctly. But I fixed the bug !

Some explanation :

In my AM I do :

        if ($VMS_STATUS_SUCCESS (stat))
	      stat = mcc_thread_create (
                mip_wait_for_disconnect,
                &dsc_mip_thread_name,
                0,
                0,
                &g_mip_disconnection_thread_id);

        if ($VMS_STATUS_SUCCESS (stat))
		stat = mcc_thread_delete (&g_mip_disconnection_thread_id);

In mip_wait_for_disconnect I do :

	if (something) then wait sometime

	g_mip_disconnection_thread_id = 0;

	return (satisfied_of_myself);

So, you have understood that if (something) is false, mip_wait_for_disconnect
exits BEFORE mcc_thread_create and set g_mip_disconnection_thread_id to 0 !!!

I have followed it under debug :

	AM call mcc_thread_create
	  mcc_thread_create set thread_id to 65XXX
	  call mcc_thread_try
	    call mip_wait_for_disconnect
	    does not wait
	    set thread_id to 0
	    exit
	  exit mcc_thread_try
	exit mcc_thread_create with thread_id = 0 

A suggestion : if you could in the SRM description of mcc_thread_create 
be more precise and say that the procedure supplied in parameter is called
DURING the execution of mcc_thread_create it'll be nice (instead of saying
"the current thread continues to execute" which can lead to misunderstanding).

Thanks and regards

Pierre.

	
	There have *no* changes to the thread-create routine for v1.1. 
	and your code fragment looks correct.
	==============================================================

	So let's diagnose this problem:
	$ define mcc_frame_log 1	! Reports ALL framework detected errors, breaks if severity=FATAL
					! (some like RMS-EOF on mir reading are not interesting, but
					! some reports might be surprising!)

	$ define your_mm_log <break>	! Want to break into to the debugger when your-mm is image-activated 
					! into the process
	$ manage/enterprise/debug
	dbg> go  	! go until you reach YOUR MM break
	...

	dbg> set break <addr of mcc_thread_create() invocation>
	dbg> go
	...
	dbg> set image MCC_KERNEL_SHR
	dbg> set lang bliss
	dbg> call mcc_thread_directory			! Display the directory of the current thread objects at t1
	dbg> SET WATCH g_mip_disconnection_thread_id  ! Will this variable be updated?
						      ! To what value?  By what PC?

	dbg> step/over	! perform the thread creation
			! Is there an exception reported?
	dbg> examine stat  ! Is the returned cvr == MCC_S_NORMAL
	dbg> call mcc_thread_directory			! Display the directory of the current thread objects at t2


	By gathering this information you should have the pieces to the diagnose the puzzle.

	
Pete Burgess

	Concerning your comment about timing and scheduling for operations:

	Today there is virtual concurrency between threads.  In a few months
	there may be physical concurrency between thread execution.  So
	*don't* try to make any clever assumptions!

	Pete Burgess
	

We'll change our design to avoid concurrency problems (since in our case it can
be done very easily).

Thanks for all the inputs.

Regards

Pierre.

    
    Some other things that you might find useful. In the Notification
    FM we do **ALOT** of thread manipulation. To work within the current
    implementation, and as Pete stated the future potential, of threads
    we tried to stick to a few implementation rules.
    
    	1) Don't pass in static variables to a thread, stick to dynamics
           and don't pass in stack variables and expect them to be
           there (remember the parent thread -- who's stack your using
           may not be sticking around)
    
        2) if you want to "share" information between different threads
           then use some type of synamic structure where you can pass
           the address of the structure in to the new thread
    
    	3) the only variables a thread owns are the ones passed to the
           thread in the param arguments
    
        4) design things so that you can handle an alert_termreq at
           any time -- even during thread create