On the Abuse of Facility Variable Implementation Specific Details

There is a concept that specific details about a given implementation should
not be used opportunistically in higher layers for portability.

One of these implementation details is the initial value of facility
variables (used by GET and RELEASE ). The fact that they are zero when
available/released is needed when declaring the variable. This
implementation specific detail could be hidden with a word such as FACILITY:
which would do VARIABLE and initialize the appropriate state. On the other
hand, because this detail isn't hidden, implementers must know and are
expected to understand it to make sure that it is set the zero.

Because this detail isn't hidden, how appropriate is it to use this
knowledge to advantage? If a certain task gets a facility and locks up,
preventing any other use of it, causing dead-lock, a watcher task could stop
that task and initialize (zero) the variable. Is this abusing
implementation specific details?

Another implementation detail about facility variables is that the value
they hold is the task base address. It is impossible for a task to have a
base address of -1. Knowing this, a facility variable could be initialized
to -1 at compile time to prevent all tasks from using it until the facility
device is initialized. The word that initializes the device could
initialize (zero) the facility variable. That seems like a clean and simple
way to manage facility start-up, but is it abusing implementation specific
details?
----------------------------------------------------------------------
swiftx_at_forth.com The SwiftX programming discussion email list
To unsubscribe, send subject "unsubscribe" to swiftx-request_at_forth.com
For list command help, send subject "help" to swiftx-request_at_forth.com
Message archives are located at http://www.forth.com/archive/swiftx
----------------------------------------------------------------------
This list is a forum for SwiftX users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Tue Jul 12 2005 - 14:49:43 PDT