Metagraphics

MetaWINDOW Developer's Guide - Chapter 9
 
MetaWINDOW Real-Time Re-Entrancy Considerations

MetaWINDOW products provide direct support for popular DOS real-mode, 16-bit protected mode and 32-bit protected-mode DOS extender environments.  A list of commercial real-time and embedded operating system vendors providing expanded support for is included in the online document:

        mw3rdpty.htm  (http://www.metagraphics.com/mw3rdpty.htm#RTOS)

Please contact the designated vendor representative for futher information in using MetaWINDOW with the associated commercial operating system products.

Occasionally MetaWINDOW applications may need to call graphic functions at times when another process or thread has already initiated calling a MetaWINDOW routine.  For re-entrant processing, MetaWINDOW functions can be divided into three classes:

  1. re-entrant
  2. software non re-entrant
  3. hardware non re-entrant

9.1  Re-Entrant Functions
MetaWINDOW functions are considered re-entrant if they are totally self-contained and use only temporary stack space for work buffers.  Re-entrant routines can be interrupted mid process, called again by another process, then resumed at the point they were initially suspended without affecting their operation.

9.2  Software Non Re-Entrant Functions
To reduce memory and/or to optimize performance, certain MetaWINDOW functions make use of a shared memory pool area and/or global work variables.  Software non-reentrant functions are not wholly self-contained, and can not normally be called by an interrupt process.>/p>

9.3  Hardware Non Re-Entrant Functions
Display controllers typically require setting up various hardware states or modes in order to carry out drawing operations.  This modal nature precludes the ability to be interrupted and resumed.

9.4  Semaphore Locking
Due to common video hardware constraints, the MetaWINDOW design controls re-entrancy at the device driver level.  This is accomplished through the use of semaphores on each hardware device structure (grafMap).  The grafMap field "mapLock" is used as a locking semaphore for the device.  When this field has a value of zero, the hardware is available for use, when it is less than zero, the hardware is in use and can not be accessed.

All MetaWINDOW drawing primitives lock the device (by decrementing the grafMap "mapLock" field) prior to using it, and unlock it when no longer using it.  Internal MetaWINDOW drawing primitives do NOT check the semaphore before using the hardware.  It is the responsibility of the external process that wants to call a MetaWINDOW drawing function to check the "mapLock" semaphore prior to issuing a MetaWINDOW function call when there is a possibility of re-entrancy (interrupt routines, multi-threaded routines, etc.).

9.5  Handling a Locked Device
What happens when an interrupt process finds the device semaphore locked?  This depends on the application.  Though rare, it may be possible to simply ignore the drawaing call at this time, and retry to access later the next time around.  More commonly, if it is necessary to have this operation continue, the process will have to defer the operation until the current operation completes, and the hardware semaphore is unlocked.  One way to do this is to request that MetaWINDOW call you back when it is done unlocking the hardware semaphore.

Semaphore callbacks are accomplished by setting the mfPending flag (0008) of the grafMap's "mapFlags" field and setting a callback function address in the grafMap "cbSyncFunc" variable.  When MetaWINDOW unlocks the hardware semaphore back to zero, it will check the pending flag, and if set will issue a call indirectly through the grafMap "cbSyncFunc" field.  A pointer can be installed to your routine at this vector.  You will be called far for 16 bit and near for 32 bit, with es:(e)di pointing to the grafMap in question.  You should clear the pending flag before your operation starts.

9.6 Related Information
A description for porting MetaWINDOW to real-time, embedded or custom operating system environments is provided in the MetaWINDOW Developer's Guide reference manual, Chapter 8 "Considerations For Porting MetaWINDOW to Other Operating Environments", also available in the online document:

       mwdvgd08.htm  (http://www.metagraphics.com/mwdvgd08.htm)

The MetaWINDOW Developer's Guide reference manual provides expanded information on porting MetaWINDOW to custom operating environments and interfacing custom graphics hardware.  This manual is included with the pruchase the MetaWINDOW Source Code product, or can be purchased separately from the Metagraphics sales office for US$39 (plus applicable tax and shipping).


Home | Products | Order | Register | Support | Company | Contact | Feedback

Copyright © 1999- - Metagraphics Software Corporation.