Conference azur::mcc

The SYS$QIOW routine is trapped by the DECmcc Threads package, and turned
into a SYS$QIO with AST.  Your thread is properly put to sleep until
the AST completes, at which time the thread is scheduled to run.

/Keith

    If your event-sink is not an MCC management module you can certainly
    make assumptions about your thread environment, but note that any MCC
    MM is subject to being entered on many threads due to alarm,
    historian, notification activity by other FMs, so even if you create
    no threads yourself within the MM.
    

    repl .2
    
    Okey, so if my eventsinker just receives messages from the entities 
    and makes it into eventreports and sends them to the event-manager
    thru MCC_EVENT_PUT and using DNS-, AES-, ILV- and DESFRAME-routines there 
    shouldn't be any problem using ASYNC QIO, right?
    
    Sorry for keeping asking, but I just want to be really sure...
    
       Thanks,
    Nils

The Event Manager uses threads

But I'm not sure if it's on the Put-side (which is where your event sink is),
or the Get-side (which is where your Get-Event directive is)

Event-Manager developers ... any insight?

/keith

    The event_get side has threads waiting for events to occur, so a
    process-blocking operation would create havoc.  The event_put side has
    operations that run to completion within a short period of time, so is
    compatible with any kind of IO.  This assumes that the sequences of
    operations is: receive external event notification in sink via the IO
    operation, put the event into the event manager via the event_put,
    repeat...
    
    One thing to note.  If you are interested in using an event to
    instruct your event sink to terminate (DECnet Phase IV AM does this),
    your sink process now has an event_get operation (wait for "please
    terminate this sink" event) competing with your blocking IO to receive
    events from the external environment.  It could wait for a long time.
    
    Ted

re: .5

>> If you are interested in using an event to instruct your event sink to
>> terminate (DECnet Phase IV AM does this), your sink process now has an
>> event_get operation ...

Good point Ted!  So if you intend on signalling an Event Sink to terminate
with another Event - you better write thread-friendly code and not block.

The fact that the SYS$QIOW is trapped and processed by the Threads Package
should take care of most any blocking problems, but...

Question>> What other VMS blocking services does the threads package process
           for you?  Like waiting on an event flag, etc...

           Likewise, what about Ultrix?  What happens here?

/keith

    >The event_get side has threads waiting for events to occur, so a
    >process-blocking operation would create havoc.
    
    I want to make sure that I understand. I am planning on having a
    multithreaded process: one thread will write to disk using dbm 
    (I am protecting the dbm routines with a cma_mutex). Another thread
    in this same process will be waiting on some events from the Event
    manager (mcc_event_get), and another thread will be perfoming an
    mcc_call .(this is on ultrix) 
    
    DOES  this pose a PROBLEM  for the EVENT MANAGER, OR FOR PERFORMANCE? 
    
    From the cma notes file note 13.2:
     "BTW, on VMS, just because a thread issues a blocking system service, it
     "doesn't mean that the whole process blocks until the service completes.
     "When the thread has exhausted its time allotment (by waiting for the 
     "system service), CMA will interrupt the process and schedule a new 
     "thread, and the process will resume execution.  So, using synchronous 
     "system services today won't cause total loss of parallelism, and, when 
     "the system services are made thread-synchronous, the remaining 
     "parallelism will become available completely transparently, without any 
      recoding."
    
    SO IS IT OK (ESPECIALLY FOR PERFORMANCE) TO PERFORM DISK I/O AND 
    mcc_event_get FROM DIFFERENT THREADS  IN THE SAME PROCESS?
    
    Carol

RE: .7

(in summary)

>> one thread will write to disk using dbm (protected with cma_mutex)
>> another thread will be waiting on some events (mcc_event_get)
>> and another thread will be performing mcc_call
>> this is on ultrix

There is no problem with this that I can think of.  Is this an event
sync process?  Is the mcc_event_get thread to determine if the the
process should shutdown?

How do you plan to construct the threads - the main thread at the 'top'
creating the child threads and waiting for them on a join_any ?

I've always thought of threads as having a 'simple existence'; an input,
an output, and something to do.  A good thread design requries a couple passes
to get things simple.

Also - it is important that each thread knows how to handle the 'alert_termreq'
status and clean up properly.

>> DOES  this pose a PROBLEM  for the EVENT MANAGER, OR FOR PERFORMANCE? 

I don't think it should

>> From the cma notes file, note 13.2 ...

This was very interesting, thank you.  For DECmcc v1.1, threads can block
other threads.  v1.2 will use CMS-threads, so what you have written should 
hold true.  A thread can only block the process for its 'time allotment'

>> SO IS IT OK (ESPECIALLY FOR PERFORMANCE) TO PERFORM DISK I/O AND 
>> mcc_event_get FROM DIFFERENT THREADS IN THE SAME PROCESS?

This should be Ok

/Keith

    Thanks, It's a process to collect and write OSI events.
    > Is the mcc_event_get thread to determine if the the
    > process should shutdown?
    Yes, or suspend and resume.
    >How do you plan to construct the threads - 
    >creating the child threads and waiting for them on a join_any
    Yes , after the join any, the main routine will use the thread id to 
    determine which thread stopped and why.

The AIM media library services (MLS) integrates with the VMS device services
by recieving requests (such as VMS MOUNT) through AST routines. Coordination
with the media library requires that these ASTs deliver work to other library
servers at non-AST level.

This work is happening concurrently with MCC management requests into MLS.
A design possibility is to queue these AST requests to a media library
thread (at non AST level) and signal this thread that new work has been
queued.

I see CMS library services for enqueueing during interrupt service routines
and signaling from ISR's, however, I don't see these offered thru MCC.
Will these thread services be available thru the MCC shared image in the near 
future (like V1.2)?

Maybe a more simplistic question would be, would DECthreads services
be available to a MOM using callable MCC routines since MCC is layered on 
DECthreads (if it is indeed layered on it)?

	/Jim