Logging In and Out

In SPEEDOS a thread can log out at any point in the course of its execution, provided that it has an appropriate capability for a Logout module. A Logout module is a normal module which can be created and used like any other module. What makes it different is only that it has a capability for a kernel instruction which "long suspends" the currently active thread.

When a thread calls an appropriate semantic routine of its Logout module it first carries out some housekeeping activities (such as releasing the user's terminal in a time sharing or transaction processing system). It then executes a (privileged) kernel instruction, which we call its "long suspend" function.

The long suspend function of the kernel advises the thread scheduler that the process is to be deactivated, and in the normal course of virtual memory management the stack's page frames in the main memory will be copied back to disc and released for other use. This is the state of a logged out process. Note that the stack of the thread still exists in the persistent virtual memory, which is one of the advantages of a persistent memory.

When at some later time the kernel detects that the user wishes to log in again, it advises the process scheduler that the process can now be scheduled in the usual way. As a result the user's thread then continues to execute in the Logout module at the instruction following the long suspend request. In a timesharing or transaction processing system it may be necessary to change the command input device to that at which the user now logs in.

The reactivated user thread (not the kernel), now executing code in the Logout module, can check that the re-activating user is authorised to log in to this thread. Since the Logout module is owned by the user, it can be programmed by the user to carry out several checks of various sorts (e.g. via a simple password, a dynamic password, a cognitive password, etc.). A check can be based on the day of the week, on a foreign language, etc. There is no limit to how this is carried out. Furthermore each user in a multi-user system can have a quite different authentication procedure, and in fact the threads creates by each process owned by the same user can have different ways of authentication.

In practice the authentication checks are separated from the housekeeping activities associated with logging in. Hence the Logout module at this point first carries out its housekeeping activities and then calls a separate (user programmable) authentication module, which checks the user and then returns with a yes/no answer to the housekeeping module.

But what if the user forgets how he should authenticate himself? A simple solution is for the authentication module to have further semantic routines for changing the check which can be called by other threads of the user.

Another potential problem is easy to solve. What if a user cannot himself program authentication checks? He could buy an authentication module from a software house!

In a business or other organisational environment the owner or other central authority could, for example, provide a separate module which is placed as the final module in the chain, so that this is the module which calls the kernel's long suspend routine. User based checks would call this module when they log out.

This scheme is efficient in that it saves the CPU processing time and disc accesses involved in creating and deleting a new thread for each terminal session and in setting up the thread to suit the user's particular requirements.

Perhaps the most important point about all these techniques is that there is no central repository for storing login information and no standard way of authenticating users, in contrast with conventional system, which make the latter very vulnerable.

And finally, because logging in and logging out do not involve deleting and recreating threads, users can quickly and conveniently log out and later resume their work at any point.