[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

526.0. "Cannot get back thread_id from mcc_thread_create" by TENERE::LAVILLAT () Thu Dec 06 1990 07:02

I used to create threads with MCC V1.0 and mark them for deletion as I am
supposed to do for clean-up. This worked fine with V1.0, but with V1.1 (both EFT
and IFT) everything goes well except that the mcc_thread_create routine send me
back 0 for the thr_id parameter. So I do not know how to delete it since I do
not have its Id.

Does the parameters of mcc_thread_create have change ?

Is there something wrong with that :

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

Thanks for your help.

Regards

Pierre.
T.RTitleUserPersonal
Name
DateLines
526.1call args -- matt will give the restGOSTE::CALLANDERThu Dec 06 1990 18:3610
    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
    
    
526.2I do not know of any changes to mcc_thread_createTOOK::GUERTINI have an in_e, you have an out_eThu Dec 06 1990 18:4017
    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.
526.3Found the bug, was my fault, sorryTENERE::LAVILLATFri Dec 07 1990 10:4854
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.
526.4thread debugging hintsPETE::BURGESSFri Dec 07 1990 12:3535
	
	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
526.5begin-mutual exclusion, read, think, write, end-mutual exclusionPETE::BURGESSFri Dec 07 1990 12:499
	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
	
526.6UnderstoodTENERE::LAVILLATFri Dec 07 1990 14:199
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.
526.7more on using threadsGOSTE::CALLANDERFri Dec 07 1990 14:4421
    
    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