TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: David Etheredge
from: Mike Bilow
date: 1995-04-11 05:56:30
subject: OS/2 programming tips ???

David Etheredge wrote in a message to Mike Bilow:

 DE> 1) I am writing a program for OS/2 that I only want one copy
 DE> to load. How can I detect whether or not a copy is already
 DE> loaded at runtime?

 MB> There are several ways to do this, but the easiest is to attempt to 
 MB> create and request ownership of a semaphore with a 
 MB> predefined name when your program starts and then 
 MB> release and close it when your program ends.   If the 
 MB> semaphore is already owned when you request it with a 
 MB> time-out of zero, then you can assume that another 
 MB> instance of your program is running.  You obviously 
 MB> need to take some care in using a semaphore name that 
 MB> would not be likely to collide with that used by 
 MB> another program.

 DE> Unfortunatly, the program can be called in the startup
 DE> routine and would most likely be in use until either
 DE> shutdown or powerdown. This means that the semaphore might
 DE> be left on disk and the program would not load during the
 DE> next startup. I am looking for something more like the DOS
 DE> Multiplex functions. 

The OS/2 semaphore facility that I was describing above does not go through
the disk.  There are API calls available which allow the use of kernel
semaphores, which are entirely contained in memory and which are
automatically extinguished when all of the processes which have access to
them are no longer running.  You need to look at the OS/2 Control Program
documentation, specifically at such functions as DosCreateMutexSem(),
DosOpenMutexSem(), DosRequestMutexSem(), DosReleaseMutexSem(), and
DosCloseMutexSem().

 DE> 3) Are you allowed to use the 1ch timer in OS/2? If not, how
 DE> can you synchronize timed events to the tic counter?

 MB> Maybe you would get better answers if you backed up a 
 MB> bit and explained in more broad terms what it is that 
 MB> you want to do.  There are numerous timer APIs provided 
 MB> in OS/2, some such as DosSleep() based on CPU time, 
 MB> others such as DosTimerXxxx() based on absolute time.

 DE> Well, I need something more reliable in order to more
 DE> reliably simulate real-time operation (which I hear is a
 DE> failing with OS/2). Interrupt driven is probably a key word
 DE> here.

Hooking the Int 1Ch vector in DOS is by no means a "real time"
facility.  As a matter of fact, the only thing that you get by hooking the
Int 1Ch vector in DOS is a very primitive kind of multitasking.  Just
running an ordinary thread in OS/2 will get you that much.  If this does
not prove adequate, you can have your thread set itself to a fixed-high
priority, and that almost always suffices.

When we say that OS/2 has no true "real time" facility, we mean
that in the context of issues such as interrupt latency and scheduler
latency.  OS/2 is really designed as a desktop operating system, but there
are ways of adjusting priorities and organizing your program to get at
least as good performance as you would from the Int 1Ch vector in DOS.

 DE> 5) is there a way to do automatic unattended shutdown and
 DE> reboot?  

 MB> Yes, and it is undocumented.  The procedure is actually 
 MB> not simple, since you have to do things very carefully 
 MB> and in a strict order, such as shutting down the file 
 MB> system.  You also have to make sure you don't kill your 
 MB> shutdown process, which requires a bit of special 
 MB> handling.  Why do you want to do this?  Programmers 
 MB> should not assume that they own the machine under OS/2, 
 MB> and doing things like shutting down the operating 
 MB> system would be viewed as not being a good OS/2 citizen.

 DE> If the operator who is using the computer that is running
 DE> one of my programs runs some other program, he understands
 DE> and wants my program to have absolute priority. The operator
 DE> would only use any other task with this understanding as he
 DE> would be at risk of considerable financial loss if my
 DE> program failed. 

You can set threads in your program to run at fixed-high or time-critical
priority if absolutely necessary.  There are even more extreme things you
can do, such as setting PRIORITY=ABSOLUTE and adjusting the TIMESLICE
parameter in CONFIG.SYS.  However, if you are writing a program that must
have total control of the machine and you never want to allow anything else
to run, then what is the point of using OS/2?  You would be much better off
using DOS.

In any case, how would abruptly rebooting the machine solve this?  If bad
consequences would ensue from even a single missed interrupt, I would
expect utter disaster to result from a reboot.

 MB> Well, as I asked, what is it that you are trying to do?

 DE> Most of the programs that I write are control programs.
 DE> Automater Water purification and distribution systems,
 DE> automated irrigation and chemigation systems, power
 DE> substation monitoring and control, environmental monitoring
 DE> and hazard alart systems, etc. All of these are MUST NOT
 DE> FAIL applications if you know what I mean.

No PC or PC-based operating system is suitable for a "must not
fail" system.  I use OS/2 and have very high regard for it, but I
would not use it as a platform for, say, a life support machine.  Some of
the things you describe can only be done properly with custom,
triple-redundant hardware.  Even if OS/2 is the world's finest operating
system, it will fail quite thoroughly if it happens to be running on a
machine with a power supply that was soldered together by prisoners in a
Chinese labor camp.

 DE> Being fairly new to OS/2 programming, I am asking questions
 DE> as fast as I can come up with them. I appreciate your help.

OS/2 can be quite reliable and is a nice platform for control software of
the general sort you are describing, but I would not trust my life to it.
 
-- Mike


---
* Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8 (1:323/107)
SEEN-BY: 105/42 620/243 711/401 409 410 413 430 807 808 809 934 955 712/407
SEEN-BY: 712/515 628 704 713/888 800/1 7877/2809
@PATH: 323/107 150 3615/50 396/1 270/101 105/103 42 712/515 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.