COSC 4F90 Project:
|
COSC home page Course Offerings Search COSC pages
This project consisted of constructing a distributed educational operating system in the Java language. The goals of the system are described. An architecture based on extendible, replaceable server components is outlined with comparison to existing systems in use today. Limitations imposed by multi-platform compatibility are discussed and reasons for the design paths followed are presented. The structures of the file system, synchronization facilities, interprocess communication, user interface, and system call interface are explained.
Description of the Project
Educational Operating System
Goals of TOS
Portability
Other Operating Systems
Nachos
Advantages of TOS
Incremental Extendibility
The Launchers as Microkernels
Administrator: why an application instead of an applet?
The File System
Implementation of a Disk
Use of the UNIX System V model
Implementation of File Security
Server Structure: Basic Principles
How Consistency is Maintained
Interprocess Communication in TOS
The Windows NT Model
Synchronization in TOS
Java Synchronization Facilities
Platform Issues
Impact of the Macintosh
Teaching Suggestions
Description of the Project
This project had as its goal the implementation of a portable, extendible, educational distributed operating system designed in the context of a microkernel-server paradigm and implemented using the Java language.
Background
Educational Operating Systems
Among the central components of any undergraduate computer science curriculum is operating systems. No professional programmer, administrator, or analyst can do their jobs effectively without a fundamental understanding of how operating systems are designed and implemented.
There is no real substitute, in learning how software works, to actually dealing with the source code. Commercial operating systems are manifestly unsuitable for this purpose. The source code of most is a closely guarded trade secret; even when it is not, the source code base is far too large for students to be able to grasp quickly. There are usually optimizations liberally scattered in a commercial system, optimizations that do improve performance considerably but detract from readability.
For this reason, there are now in use many purely educational operating systems, with a much simpler set of features and smaller code base, generally designed and implemented entirely by academics. Some of these boot directly from the hardware, but the majority either run over a native operating system or over a software simulation of the hardware.
Distributed Systems
The majority of educational systems today rely heavily on the UNIX approach to operating system construction, which has dominated both the industry and academia for nearly a quarter of a century. This author is not a critic of UNIX, but it must be realized that new developments in computing today cannot be reflected in the traditional framework.
The most important is the concept of distributed systems. In commercial settings, applications are already routinely constructed that run over many different computers of different architectures. Catching up to this is the distributed operating system, one that runs on many computers simultaneously, and provides applications with a single system image regardless of what location the application happens to be situated in.
Distributed educational systems in use today, such as Amoeba and Mach, suffer some of the same limitations as commercial systems; they are sufficiently large and complex that their source code does not lend itself to thorough examination in a one-semester undergraduate course. In addition, it is important that the impact of the distributed paradigm not totally overshadow the fundamentals of operating system concepts. The future likely holds a mixture of single-computer and multi-computer operating systems, not the elimination of the former entirely.
For these reasons, there is a definite need for an educational operating system sufficiently simple to cover the core topics of operating system design, and yet include many of the key features of distributed systems.
Microkernel-based Architecture
The classical design of an operating system is that of MULTICS and its descendants - a monolithic kernel built as a layered structure. The bottom layer deals directly with the hardware and maps hardware calls to a set of primitives it offers the next layer. Each layer offers an interface to the layer above it and deals with the layer immediately beneath it. The top layer offers a system call interface that user programs may use.
In a distributed environment, such an architecture loses a good deal of its usefulness. Since the kernel is in essence a single monolithic unit, albeit a layered one, it must be accessible to every machine in the system. There is no easy way to achieve this. One way is to simply place a copy of the kernel on every machine in the system. This leads to a potentially enormous amount of redundancy and sacrifices most of the advantages of using a distributed operating system in the first place, since the end result is essentially a networked set of machines each running their own kernel.
The alternative would be to place the kernel on one machine to which every other machine must make calls to in order to utilize system services. Such an approach is inherently unscalable. Were the distributed system to grow very large, the strain on the machine running the kernel would inevitably become unsustainable.
Instead of the monolithic kernel, then, a design scheme that has gained increasing popularity in recent years is the microkernel approach. In this paradigm, every machine hosts only a small section of the kernel. The rest of it is delegated out to machines designated as servers. Each server offers only a subset of system services. One machine acts as a file server, another as a device server, and so on. There can be more than one server machine for each type of functionality.
This is a more scalable approach, since system expansion can be matched by increasing the number of servers to match. It is also more modular and modifiable, since any one server component can be replaced without having to rewrite other components, as long as the defined interfaces between components remain the same.
Unfortunately, few educational operating systems, as yet, make use of this technique in a way that is simple and small enough for students to easily observe. This is unfortunate, as it can leave students with a mistaken impression that the traditional monolithic approach is the only effective way to build operating systems.
The Value of the Java Language
Being educational does not spare an operating system from some of the same pitfalls that bedevil commercial systems. Perhaps the single biggest problem is portability. Different academic settings use a widely variegated set of hardware and native operating systems. An educational OS written for one platform usually does not port easily to another without a good deal of effort. Instructors often cannot use the product they would prefer in their courses because they do not have access to the platform needed to run it.
Academics are not overly fond of industry buzzwords, but Java is one exception, as the rapid adoption of this technology in recent years in university curricula demonstrates. As a programming language, Java eliminates many of the criticisms that can be made of the previous industry language standard, C++. Java boasts language-level support for threads and runtime exceptions. It compiles to a platform-independent bytecode that makes porting to other hardwares very nearly trivial. It is fully object-oriented, not a hybrid like C++. Its use of automatic garbage collection for out-of-scope objects and its deliberate lack of a pointer mechanism make impossible some of the most frequent and expensive bugs in C++ programs.
Goals of TOS
The main goal of this project was to design and construct an educational operating system that makes use of a microkernel-based structure. It runs in a distributed environment without obscuring the core functions of an operating system. It is implemented in the Java language to facilitate portability, and it supports user applications also written in the Java language.
In choosing a name for the new operating system, the author has decided to throw modesty to the dogs and use the name Tyrone's Operating System, or TOS.
Design Constraints
Portability
TOS had to be portable to as many hardware platforms as possible. The immediate goal for this project was to be able to run on the three platforms in common use at Brock University, these being Microsoft Windows, Apple MacOS, and Silicon Graphics IRIX. That meant that Java code had to be used as much as possible and native modules to be avoided, even if that meant sacrificing performance. Assumptions about the host operating system had to be kept to a minimum.
All-Java
TOS was to be implemented entirely in Java. Native code, if it were to be used, would almost certainly end up using platform-specific functions that would only confuse students. This did impose some constraints on the system where the use of native code would have simplified matters. In the commercial world applications written in Java often are forced to rely on short sections of native code. Even the Java class libraries themselves contain substantial amounts of native code.
Extendibility
This project will almost certainly not be the final word on TOS. There is no reason the code base cannot be used for other senior-level computing projects. It can conceivably be extended to the point where it is viable for use in commercial distributed Java applications. For this to be possible, its design had to be scalable to a large number of running hosts and users, and had to be written with a later goal of commercial usage firmly in mind.
Other Operating Systems
Nachos
Nachos was the model cited in the original proposal for this project. Developed at Duke University in 1994, it was tied very firmly to the MIPS hardware it was originally built upon. Nachos was built upon a simulator of the MIPS processor, complete with interrupts, a clock, and paging system. The kernel, running to this machine, provided thread switching, a simulated virtual disk and filesystem, and synchronization and process handling services.
Nachos suffered a number of disadvantages. Its use of a MIPS simulator obscured its teaching effectiveness for students unfamiliar with MIPS hardware. The kernel also had no bootstrap mechanism of its own; the only way a user could start the system was by cross-compiling an application to run over Nachos, which would then be linked statically with the Nachos kernel. This placed limitations on how effectively students could see the inner workings of the system. There were few utilities to actually view and observer system contents or data tables.
Nachos did have some innovative features. One, imitated by TOS, was in simulating a virtual disk drive rather than merely building a file system on top of a host file system. In this way, students get to see the ins and outs of low-level I/O to disk that cannot be as easily made clear by an approach like that of Xinu (see below).
Xinu
Xinu ("Xinu Is Not Unix") was developed jointly by Purdue University and AT&T Bell Laboratories. Originally developed to run over MS-DOS, it has proved more amenable to porting than Nachos, and was used in its Apple Macintosh incarnation to teach operating system implementation at Brock University. Xinu provided a nearly complete range of system services, but in other respects relied largely on its native system for support. Its file system, for instance, was merely a wrapper to the underlying Macintosh file system. As with Nachos, users made use of a cross-compiler to create programs; further, they even had to link it directly with the Xinu kernel in order to run their applications! Thus the only effective way for the user to run more than one process was for one process to explicitly create another.
The Xinu code base also contained liberal quantities of platform-dependent code. Students at Brock University, including the author when he studied Xinu, were forced to wade through dozens of references to Macintosh functions that were not documented in the Xinu text. They had only the function's name from which to infer its operation, and this only detrimented their understanding of Xinu operations.
Despite its name, Xinu did offer many similarities to UNIX, the system whose internals students were most familiar with. It also offered a well-organized, comprehensive, and neat system architecture.
JavaOS
No discussion of a Java-implemented operating system is complete without JavaOS, Sun's platform for Java intended for use on legacy computer systems, network computers (NCs) and a wide variety of embedded devices and appliances. JavaOS provides all the functionality of an operating system on which Java programs can be run.
It might be thought that TOS could be built using JavaOS as a reference model. Such an assumption would be mistaken. JavaOS bears little resemblance to TOS, either in its targets or its basic design philosophy. For starters, it is not a distributed operating system at all, but a unicomputer operating system intended merely to be portable even to small handheld devices or household appliances.
Secondly, despite its name, JavaOS is not entirely written in Java. All operating systems must, at some point or another, deal directly with the hardware, and that means a layer of native code is essential. The core of JavaOS is thus written in C. Use of C code violates one of the key design principles of TOS, that it be implemented entirely in Java.
JavaSpaces
JavaSpaces, not JavaOS, is the nearest thing Sun has to a distributed operating system. Like TOS, JavaSpaces is based on the principle of providing a unified, consistent set of services for distributed applications already running on top of a native operating system with its own copy of the Java virtual machine. However, emulating its design would not be advisable for an educational system.
Fundamentally, JavaSpaces offers just three operations, write, lookup, and take, with which applications can pass information into and retrieve it from an object called a space, which acts as an object-independent repository for data. Distributed application developers may find this highly useful, but students learning how operating systems work will not. JavaSpaces is, after all, not an operating system but a framework in which distributed applications can be deployed. It is true that frameworks dominate the marketplace today and all but exclude true distributed operating systems, but that may change.
Advantages of TOS
Portability: TOS does have explicit installation files for Windows, UNIX, and the Macintosh, but porting to other platforms will be almost trivial. The only platform-dependent code is a small if-elseif structure to choose the look and feel for GUI components, a single line of code in the console in which user applications are run, and the native packaging used to start TOS executables, which is not actually Java code at all. The Design Specification had anticipated needing a platform-dependent layer to run applications, but in fact it was not necessary.
Virtual Disk: TOS provides an excellent overview of some of the most basic operating system concepts. One particularly noteworthy feature is the virtual disk facility. Instead of creating files by simply wrapping the host's native file system, TOS actually contains "disks" that are implemented entirely in software and saved as only one native file. This again is a concept borrowed from Windows, albeit in a much different concept; Microsoft's OLE Structured Storage technology, in which objects created by many different applications and with different structures are saved by a container application into a single compound file.
Thus, students can see low-level interfacing with an I/O device and yet not sacrifice all the benefits of hardware independence that Java provides. The only one who suffers, of course, is the author of TOS, who has the added labour of designing and implementing this virtual disk in addition to the rest of the file system. Since the author's motto is never let sleep stand in the way of science, this did not prove to be an obstacle.
The Java Run-time Environment
As was discussed above, the widespread acclaim that Java is receiving in both academia and industry is well justified. The language cannot truly be said to incorporate the very latest advances in programming language theory, but nonetheless it manages the rare feat of providing a base for robust, stable programs while giving programmers many casual similarities to their beloved C++.
The use of Java as both the system language and application language naturally has a considerable impact on the layering of the system. Certain facilities that traditionally are part of an operating system have been omitted from TOS completely without compromising the system's quality. These are:
1) Scheduling. Threads are a part of the Java language and their scheduling and context switching is the responsibility of the Java Virtual Machine. Providing a separate threading mechanism for TOS would have been reinventing the wheel. Instead, TOS has extended the Java threading mechanism to allow communication between and coordination of threads located in different virtual machines on different computers.
2) Memory management. Java programs do not have to worry about memory. The Java Virtual Machine provides applications with all the memory they need. The VM handles the nuances of obtaining more memory from the underlying host operating system. Java programmers do not even need to concern themselves with returning memory they no longer need to the system, because of the VM's automatic garbage collection mechanism which automatically deallocate objects with no references to them. Any concept of a global, TOS-wide stack or heap would be both redundant and unnecessary, and has therefore been safely omitted.
The Java RMI Libraries
Version 1.1 of the Java Development Kit (JDK) introduced the Remote Method Invocation system. This is the component that makes TOS possible. RMI makes possible the seamless invocation of a method of a remote object as if it were local. Every one of the server processes in TOS is such an exported remote object whose functions are thus easily accessible to any client process.
The JDK comes with a simple tool, rmiregistry, which can be run from the command line or invoked via the static library function Registry.createRegistry(). This tool sets up a network port on which to listen for remote calls. Any client can look up objects exported to that port using the Naming.lookup() function, which takes a URL as an argument.
When clients make use of a lookup function, the RMI libraries return a remote stub object, which to the client is a remote object. The client is then free to make remote calls freely, without having to concern itself at all with the distinction between local and remote.
Remote stubs are serializable objects. This means they can be passed as parameters to other functions or even to other processes. TOS makes considerable use of this; it is, in fact, the main method different servers use to keep track of system objects. Any pipe server can thus deal with any pipe; any synchronization server can deal with any synchronization object. The magic of RMI remote stubs makes it all possible.
Basic Structure of TOS
TOS may run on any number of machines, as long as they are connected on a single physical network, intranet, or the Internet. To start TOS on a machine, a user must run the launcher program. The first launcher to run will also start up a filename server, pipe server, and sync server. Other launchers to join the system must connect to an already-running launcher.
Most of the functionality of TOS is provided in servers. The pipe server deals with the interprocess communication, which is provided via objects called pipes, logical information transfer mechanisms running on a full-duplex basis. The sync servers manage the three types of synchronization objects TOS provides; semaphores, mutexes, and signals. File name servers have the responsibility of mapping filenames from the global namespace to their physical locations.
The TOS file system uses virtual disks, software-based simulations of real disks that are stored as a single physical file on the underlying host. Individual TOS files can be created and manipulated at will regardless of what virtual disk they are located on.
To administer the system, the user must run the GUI Administrator program. This can be run from anywhere on the network, not necessarily a machine running a launcher. Once it connects to one of the launchers, it can display information about the hosts in the TOS system, the running processes, servers, and disks, and individual pipe and synchronization objects. New servers and disks can be created or removed from the system; deadlocks can be broken by killing processes or directly manipulating pipes or synchronization objects.
TOS also has a Console program, providing a command-line shell through which users can navigate the file system and create and destroy files. They may also edit, compile, and run Java programs directly.
User applications that make use of TOS are derived from an abstract class created for this purpose, called TOSProcess, that provides access to system services without permitting subclass developers to see the details of the implementation.
Overall Considerations
Incremental Extendibility
A new launcher, server, or disk can be added at any time and removed at any time without affecting the functioning of the rest of the system. User programs need not have to worry about the physical location of disks, servers, and launchers. The single launcher they connected to will provide them access to the entire system.
Universal Access Points
An application program, upon starting up, has only to connect with one launcher. That launcher will provide the application, either directly or indirectly, with all the references to servers and disks that it needs, regardless of their locations. The nuances of dealings with servers and disks are in hidden sections of the user application, leaving the programmer with largely hassle-free use of TOS system services.
The same principle is applied within the TOS architecture itself. Launchers do not have to search for and make direct contact with individual servers; each one maintains a reference to a single server of each type and uses that reference to access the entire subsystem. The only exception to this principle are disks, which have to be persistent and therefore deal directly with their launcher.
TOS Services in Client-Side Code
This author makes no apologies for the influence of Windows-based ideas on TOS, given his own career as a professional Windows developer/analyst. Windows has some of its operating-system functions running in the processor's kernel mode, and other functions located in user mode as dynamic libraries that at run time are actually loaded into a process' address space.
An analogous design exists in TOS. Every TOS application must be descended from the class TOSProcess, which has private data structures and functions that implement a considerable part of TOS functionality. The entire file access layer of the file system resides in client-side code. The TOS disks only export functions to read and write individual data blocks; the business of reading from and writing to files, traversing directories, and checking passwords is all found in client-side code. A similar situation exists in the synchronization system, where the client process itself contains the code to suspend and resume threads based on instructions from the server.
In fact, every TOS process is actually an RMI server and exports a remote interface that is an important part of TOS functionality. This server is private and thus inaccessible to programmers, yet they enjoy all the benefits it provides.
The TOSProcess class even hides the special thread that the RMI runtime libraries create to receive requests and automatically terminates it when all non-daemon threads created by the client terminate, giving the user the impression they are operating like any non-remote Java application.
The Launchers as Microkernels
In designing any microkernel-based operating system, a decision has to be made as to where to draw the line between the responsibilities of the microkernel and those of the modular servers. The less functionality a microkernel has, the greater the flexibility the operating system as a whole enjoys, as server components can be more easily replaced or rewritten than microkernels.
On the other hand, functionalities implemented in the microkernel will be more easily available and accessible to other system components, because of the microkernel's presence on every machine running the system. In situations where network communication times are significant, larger microkernels may result in a significant performance improvement.
The TOS microkernels are known as launchers. They have three basic functionalities:
1) Starting and stopping servers
Most computers do not permit a program running on another machine to remotely start a process. To get around this, a launcher must be started directly by a user on every host that will be running TOS server components. Once the launcher is in place, it can make use of the Java Runtime.exec() function to launch other servers. Similarly, launchers can be employed to force the shutdown of any running server.
2) Providing access points
End users never see the servers, only the launchers. The launcher signifies the presence of TOS on a host and is the single point to which user-written applications connect to deal with the operating system. Remote references to other servers are not obtained directly but are provided by the launchers.
3) Maintaining system tables
Launchers maintain lists of every server running on the system, for the purpose of being able to provide this information to the user (via the Administrator) and to be able to add and remove servers easily. Arguably, this is redundant, since the servers themselves of necessity also maintain lists of other servers of their class, but it is also more robust. The risk of inconsistency is there, to be true, but TOS carries out updates to the tables in the launchers simultaneously with those in the servers, so it is not a worrisome factor.
The User Interface
Complete details of the Console and Administrator can be found in the User's Guide and Administrator's Guide, respectively, and shall not be repeated here. Some design considerations are worthy of examination, and these are looked at below.
Administrator: why an application instead of an applet?
It might be argued that the Administrator utility should have been made a Java applet instead of an application, allowing users to make use of the familiar web browser to access it. This, however, suffered several disadvantages. The most important is the security restrictions browsers apply to their applets. An applet cannot connect to any TCP/IP server other than the one it was loaded from. This would rule out more than half the features of the Administrator, which rely on direct contact with TOS server components which can be located anywhere on the network. Secondly, it would require running launchers and servers on hosts that are also running an HTTP server, an unnecessary restriction when all that TOS needs to run are RMI servers.
Console: why not a GUI?
Another criticism that can be made is the choice of a command-line console to navigate the file system. Why use a command line for users and a GUI application for administrators? The simplest answer is students studying Java code could see both in action. There is also the consideration that many students will be using telnet sessions into a UNIX host to run TOS, an environment that does not allow GUI programs to be displayed. The flip side is that, despite Apple's promises to the contrary, there is no way of writing interactive command-line Java programs for the Macintosh without writing native code using the JManager libraries to receive input from the user. The generic JBindery tool provided with the MRJ SDK does not cut it.
Use of the JFC/Swing libraries
TOS' GUI services are provided by the Java Foundation Classes (JFC) library, also known as Swing. These offer a number of advantages:
1) Although not a part of Java 1.1, they will be made a part of the core Java API in Java 1.2. This enhances the extendibility of the code.
2) The JFC libraries allow the developer to quickly customize the look and feel of the application with a single line of code. This enables TOS to display Windows-style icons, fonts, and shapes while running on Windows, Motif-style objects running under Motif, and Macintosh-style appearances under the Macintosh (although admittedly, the JFC implementation of the Macintosh look and feel leaves much to be desired).
3) Unlike the AWT libraries, which are based on calls to a set of peer classes which in turn are written largely in native code, the JFC classes are constructed almost entirely in Java. This makes them more lightweight and takes up a lesser load of system resources.
The File System
Implementation of a Disk
Taken from Nachos is the idea that, unlike Xinu and most other educational systems, TOS does not simulate merely the file system but the disk hardware itself. This adds greatly to the development effort to build the system, but, as was mentioned previously, the author's favourite motto is never let sleep stand in the way of science.
The author's own professional background in Microsoft Windows programming led to the use of Object Linking and Embedding (OLE) structured storage as a model for the TOS disk. Windows applications that are OLE containers can create documents which contain objects produced by any number of different OLE server applications. These can be saved into a single compound file. The operating system sees this as a single file, but the OLE container treats it as, in effect, a directory containing several files.
Thus, a compound file created by a container like Adobe PageMaker can contains, internally, different virtual files, one for Microsoft Word text, another for a Microsoft Excel graph, another for a CorelDraw image, and so on.
The TOS disk runs along similar lines. The host operating system sees it as a single binary file, but TOS has neatly organized every byte in it so that it resembles a physical disk.
Use of the UNIX System V model
There are dozens of different file systems in use in many different operating systems. For an educational system, however, it is best to create something that students can easily relate to. The majority of undergraduates possess a familiarity with only two file systems, those used in UNIX and those in MS-DOS and its descendants.
Disks running on Intel machines have a master boot record and a partition table. The latter divides the disk into one or more logical disks, the former identifies which of these logical disks is used to boot the computer. A partition using the MS-DOS file system will then contain a File Allocation Table (FAT) which contains an array-implemented linked list of disk blocks for every file in the operating system.
The problem with this is that if anything happens to the FAT, which is only a small section of the disk, the entire disk can become unusable, as countless MS-DOS users have discovered to their considerable grief. Placing so much information about the filesystem in a single location is not a good example of robust design.
UNIX, by contrast, places only global information about the file system in the introductory block, called the superblock. Every file then has a structure called an inode, which contains basic information about the file and a linked list of data blocks containing that file's data.
TOS models itself on s5fs, the original System V file system designed in the late 1970s. Few commerical UNIX implementations still make use of this system, which lacks the dozens of optimizations and enhancements that have been introduced since then. Nonetheless, it has, as is typical, the advantage that the commercial systems do not have - simplicity of implementation.
TOS does introduce a distinction that s5fs does not have - a genuine difference between in-memory objects and on-disk objects. When s5fs opens a file, for instance, the corresponding inode is loaded into memory and added to the kernel's in-memory inode list. The in-memory version is structurally identical to the on-disk version. Not so in TOS - the format of data structures routinely differs. TOS saves to physical disk only what is absolutely necessary to be saved.
In addition, given that network problems and crashes are likely to be more of an issue with TOS than with s5fs, robustness and consistency are greater considerations. Caching, which improves performance at the expense of robustness and consistency, has therefore been kept to a minimum. Only the writing of data blocks is cached; writes to the superblock, free list, or inodes are not cached but are written to physical disk at once.
The internal structure of a TOS disk consists of the following sections:
Superblock
The on-disk superblock contains just three essential pieces of information about the disk - the maximum number of open files, the number of data blocks, and the size of each data block. When the disk starts to run, the on-disk superblock is loaded and used to create the in-memory superblock, which calculates other pieces of information, most importantly the locations in the host file of the beginning of each section.
Free list
Any block in a disk is either allocated to a file or free. If it is free, it is kept on the free list. Since the total number of data blocks is of a known fixed size set at disk creation, the free list can be stored on disk as an array, with the index serving as an identifier of the block. Each block can thus be marked as used or free.
In memory, however, a different scheme is used, since it is important to be able to allocate and free data blocks with maximum speed. When the disk starts running, the byte array on disk is converted into a Java stack object. Blocks can then be allocated and freed merely by simple push and pop operations.
For maximum robustness, however, every single allocation and deallocation of a virtual disk block results in an update to the free list on the physical disk immediately.
Inodes
Because the maximum number of files the virtual disk can store is fixed at disk creation time, the on-disk inode list is of a fixed size. The inode holds basic information about each file (its name, password, permissions etc.) and pointers to its first index block and data block.
One key difference from UNIX is the lack of an in-memory inode list in the kernel. As is explained below, inodes are loaded into memory when a TOS file is opened, but they are loaded into the application's address space, not the disk's. The disk itself does not keep track of which files are open and which are closed. Nor does it need to; since there is no caching the on-disk version of each TOS file is always up to date.
Data blocks
At disk creation time, administrators specify the size of each data block and the number of data blocks the disk will contain. Administrators must manually ensure that the host machine has sufficient space to store the disk. As is the case in Nachos, the physical disk file does not grow as data as added to it; it is created on the host already at its maximum size, filled with zeros. This avoids the risk of growing disk files running out of space on their host.
As is the case with any file system, the size of the data block involves a tradeoff between space use and speed. Large data blocks can lead to inefficient use of space, if there are many files smaller than the block size, or if the last data block of each file routinely has a small proportion of its bytes filled. On the other hand, small data blocks can lead to excessive fragmentation, as many of them must be allocated for larger files and these are often non-contiguous. At first, this might seem a problem for TOS, one that would necessitate the development of a disk defragmentation utility.
However, since this is a virtual disk, not a physical disk, the latency and seek times make themselves felt at a much lower layer - the host operating system's access to the physical file. This is outside the purview of the Java Virtual Machine and cannot be dealt with without writing platform-dependent native code. Given both the all-Java design objective and the fact that in actuality most TOS instances run by students will have a comparatively small number of files and data, the issue is not significant.
Indexing
The TOS indexing system is kept much simpler than that of s5fs. There is no concept of indirect indexing as in s5fs, where one index entry can be a pointer to an entire table of indexes. TOS files use a single index, which can be spread out over as many data blocks as necessary. The inode holds the location of the first index block; during reading or writing the data blocks to use can simply be obtained by traversing the index block. Each index block has as its last item the location of the next. There is no limit to the size of the index itself, except, of course, the fact that no one file can use more data blocks than the disk has available to allocate. This will place a limit on the number of index blocks any one file could ever need.
There is, admittedly, a potential scalability problem with such a design, but it would occur only if a very large disk were created with a very small block size, which is inadvisable even for commercial systems. (Windows, for one, automatically sets the block size based on the size of the disk being formatted and does not allow users to change it, for this very reason.)
Implementation of Files
The most striking difference between TOS and s5fs lies in the location of the code that actually navigates the files themselves. In s5fs, a non-object-oriented system, applications make use of system calls which are implemented inside the kernel. Not so in TOS. The Java class that deals with most of the nuances of individual files is TOSFile, which is executed inside the application process, albeit with its operations and fields hidden from the application programmer using Java access modifiers.
The great advantage of this approach is that it leaves the disk with all that much less to do. Most of the calls the disk receives will be to retrieve and write data blocks as a whole. The details of determining which blocks to read and write, to say nothing of interpreting the data contained therein, all lies within the application. This is a very scalable approach, since increasing the number of open files will not increase the amount of processing the virtual disk has to do. Nor would increasing the number of applications accessing the disk.
What might be questioned is the security of this method - the possibility that much of the functionality of the operating system could in effect be modified on the fly, perhaps malevolently, by an application program. This is not as great a risk as it seems. Most of the code within the TOSFile class is protected, so the programmer only sees an opaque TOS file object, not the internal operations it is carrying out.
A full technical explanation of this class is found in the Developer's Guide. Briefly, a file is opened first by searching for it along the directory tree, then loading its inode into memory, performing security checks if necessary. The first index block and first data block are loaded into memory if the file has been opened for reading or writing; if opened for appending, the last index and data blocks are opened.
The file is handled on a sequential basis; there is no seek() operation as in random-access files. Once the user has come to the end of a data block, it is send to the virtual disk to be written to the physical file. The number of the next data block is obtained from the in-memory index block and obtained from the virtual disk. A similar procedure is followed when coming to the end of an index block.
When a file is closed after having been open for writing, the numbers of the last index block, last data block, and last position within the last data block are written in the inode. The reason for this is that there is no EOF character that can be guaranteed not to be used for any other symbol under any character set. Using the Unicode EOF character (0x07) won't do if the native character set is single-byte, becuase of the zero in the upper byte. EOF characters are therefore dispensed with.
It is entirely up to the application what data is to be entered into the file. There are readChar() and writeChar() methods that will write Unicode characters as two separate bytes, but applications are not necessarily required to make use of this. As far as the file is concerned, there is no difference between text and binary files, although the TOS console does make such a distinction (see the User Interface section of this document).
Implementation of Directories
As in UNIX, a directory is simply a file. The contents of a directory are merely the names of each file and their respective inode number separated by the / character. New directory entries are simply appended to the end of the file. If existing entries are removed, the entire file is rewritten so as not to have waste space in the middle of the directory file.
Directories have the added advantage of shortening considerably the time needed to located a file on the virtual disk. When given a file, the first directory in its absolute path name is searched for within the root directory of the virtual disk. Linear searches are thus only necessary within directories, and not for the disk as a whole as would be necessary otherwise.
Implementation of File Security
The classical UNIX security system assigns ownership of every file to a user, who then has the authority to issue differing permissions to each file. This, of course, assumes that the system has a user table and complete subsystem for managing users.
It can be questioned why TOS does not have a similar feature. Users do not log into TOS and enter a password, as they must in UNIX and even Windows NT; they simply get in with no authorization measures at all, as in the much-maligned MS-DOS.
The reason for this is the transient nature of TOS. Because of its use largely by students, no one instance of TOS is likely to be running for more than a short time. Many instances will only have a single user; few indeed will have more than a very small number of users. It was deemed too great an inconvenience to have to set up user accounts and passwords every single time TOS is launched in order to use even the most basic features of the file system.
The way out is to use passwords for each file. Any user can assign a password to a file using the console's protect command. Once protected, permission bits can be set on a file using a syntax similar to that of UNIX using the chmod command, but with one digit (world) instead of UNIX's three, since TOS does not have users and groups as UNIX does.
Passwords do have the drawback of having to be entered with every command that accesses a protected file. Commands like move and copy, which deal with more than one file, have to use prompts to allow users to enter file passwords without confusion. Nonetheless, the simplicity offered by a password-based approach was considered by the author to have more merit than demerit over the login-based apporach.
How Location Transparency is maintained
The original design of TOS called for a naming system along the lines of MS-DOS and its descendants, where the physical location of files would be known to the user. After some reflection during the development process, it was felt that this was insufficient. Accordingly, a more UNIX-like look was adopted. As under UNIX and NFS, system administrators can now mount disks to directory names as part of a single global namespace. Hidden layers of the client application know where the physical disk actually is, but since this information is stored in private data structures, it is inaccessible to the programmer.
Implementation of File Names
The TOS console and user applications deal in path names in a global namespace that is not shared internally by any of the TOS virtual disks. It is the filename server's responsibility to map names from the global namespace into the namespace of the virtual disk the file in question is located on.
Names are chosen in the TOS Administrator program, which permits the mounting and unmounting of virtual disks to and from the global namespace.
Server Structure: Basic Principles
Although the launcher and virtual disk can be thought of as servers, for the purpose of this section the word server should be taken to mean the pipe server, filename server, and sync server. These three are run from Java classes that inherit from the Server abstract class.
How consistency is maintained
Although different objects are handled by different servers, every server knows which other server handles every object of its class in the system. Thus, for instance, if a pipe server receives a request for a pipe that it does not store in its own tables, it can refer the request to the correct pipe server. The group of pipe servers, collectively, then, form a "black box" from the viewpoint of the rest of the system. Contact with one server enables contact with any other.
How scalability is maintained
The black-box approach means that the addition of more objects to the system is not an issue, as long as enough servers are added to handle it. The only caveat is that, eventually, the number of servers could grow large enough that mapping objects to their implementing server could become an overly time-consuming operation. It would not be difficult, however, to modify the server structure to allow some type of classification of objects to avoid this problem.
Interprocess Communication in TOS
The Windows NT Model
Educational operating systems have a disappointing tendency to use IPC mechanisms considerably less useful than what is appropriate for the modern age. The message-passing mechanism used in Xinu suffers the disadvantage that every message is discrete and cannot be read smoothly.
A model that suggested itself fairly soon to the author was the named-pipe mechanism of Windows NT. NT processes can create a pipe, and other processes can connect to that pipe by name. The creating process can then send data down the pipe and have it received at the other end. Each process maintains a handle to the pipe, which can be passed as a parameter to other functions, threads, or even other processes.
TOS goes even further than this. NT's pipes are half-duplex, but TOS pipes are full-duplex. In that respect, a TOS pipe can be considered the equivalent of a pair of NT-style pipes, since data sent in one direction does not collide, or have any other effect on, data sent in the other direction.
The only disadvantage is that TOS pipes can be accessed by only two processes, one at each end, making them unsuitable for broadcast use. A workaround for this is if the processes that wish to receive broadcasts place the connection to the receiving end of a pipe inside a mutex-guarded critical section, so that each receiver connects to the same pipe one after another. This does mean that the sender must resend the data for each recipient, but the job will be done. Broadcasting was not, however, a major design consideration for TOS pipes (nor was it for NT, which uses unnamed pipes for that purpose); a different subsystem can be added to TOS in a future implementation.
Java Objects Implementing Pipes
Pipes are represented on the client side by the Pipe class and on the server side by the InternalPipe class. The client-side class does little but wrap calls to the pipe server and keep track of which side of the pipe the calling process is on. The server-side class maintains copies of the data that have been written to the pipe until they are read from.
See the Developer's Guide on these classes for more details as to the operation of pipes.
Synchronization in TOS
Java Synchronization Facilities
Synchronization in most operating systems is based on data structures called monitors - once a lock is placed on a monitor object of some kind, no other process can access that object until the locker has released it. Sections of code can be guarded against use by more than one thread by having an object locked at the critical section's beginning and released at its end. This can be encapsulated in data structures called mutexes or semaphores.
Java, notably, features such a facility at the language level using the synchronized type modifier. A section of code, or even an entire function, can be guarded by the use of a lock on any local or class instance variable. This, in fact, is far more convenient than having to use the platform-dependent system calls for synchronizatino required by languages like C++. However, the synchronized modifier is only effective among threads running in a single Java virtual machine, diminishing its usefulness in distributed applications.
The Windows Model
The Windows family provides three types of synchronization objects in its API;
- the semaphore, which allows a fixed number of threads into a critical section and blocks any threads beyond that number;
- the mutex, which operates essentially as a semaphore with its fixed number of threads always 1;
- the event, which if in its signaled state will allow any thread to pass through, but if set to its nonsignaled state will block every thread. Threads can in effect be told when to proceed by another thread setting a nonsignaled event to signaled.
These provide the programmer with a good deal of flexibility. The event object, in particular, allows synchronization to be used for timing and coordination of different threads, not just guarding access to resources or critical sections.
TOS provides these same three types of objects, changing the name of event to signal to avoid confusion with the java.awt.Event class.
Java Objects Implementing Sync Objects
On the client side, there is an abstract superclass SyncObject, with subclasses Semaphore, Mutex, and Signal. The client's listener thread contains the code needed to suspend and resume threads when needed by a synchronization object.
All three object types are dealt with on the server side through the single class SyncRecord, which has a field marking the object's type.
For more information see the Developer's Guide.
Platform issues
TOS was designed and built on the computer in the author's home, which runs Microsoft Windows NT 4.0. The compiler used was beta 2 of Microsoft Visual J++ 6.0. It is true that Visual J++ has come under considerable criticism from the Java developer community for its non-standard extensions to the Java language itself and its failure to support RMI or the Java Native Interface (JNI). Nonetheless, it was judged the easiest and fastest development environment available. The author disabled Microsoft language extensions and substituted Sun's implementation of the JDK class library for Microsoft's during the build process, so as to maintain PureJava compatibility. All of TOS is 100% PureJava.
Impact of the Macintosh
The author relucantly admits, despite being an ardent advocate of the Apple Macintosh during his own undergraduate years, the process of developing TOS did not endear that system to him.
The TOS console was designed as a non-GUI application. This can be done without much difficulty on most operating systems, but not the Macintosh, to whom all applications are GUI-based. Any console application to run on the Macintosh must therefore have some sort of GUI wrapper for the console.
This consideration has come up before for Brock University in its usage of the Macintosh. Until recently, Modula-2 on the Macintosh was used to teach introductory computer programming; console input and output was handled by Modula-2 libraries which made use of a special "TextWindow" in which console I/O could be made.
Apple does, in fact, provide a similar wrapper for Java applications. The Macintosh Runtime for Java Software Development Kit (MRJ SDK) contains MRJToolkit, a simple set of libraries with which Java programs can deal with basic operations of the Macintosh shell; JManager, a library through which Java programs have access to the entire Java API, and finally JBindery, a simple tool that wraps Java classes into a package that can be started easily from the Macintosh Finder (shell). It was JBindery that the author used to prepare the Macintosh version of TOS.
Two problems soon emerged with this:
1) Apple's promises to the contrary, the present version of JBindery does not support redirecting standard input to a Java console window. That means the TOS console is in effect inoperable on the Macintosh, since the user is left with no way to type in commands. The only way around this would be to implement an equivalent of JBindery using the JManager library, but, since this in effect means writing large quantities of native code, this was not done. As a result, the TOS console is not currently supported on the Macintosh.
2) The Macintosh lacks a command line for its applications. On UNIX and Windows, parameters can be passed to any application merely by entering space-delimited argument lists on the command line. The only equivalent on the Macintosh is dragging a document over the application's icon in the Finder, which sends an Apple Open event to the application as it starts. To use this mechanism in TOS would, once again, involve the writing of native code.
The author decided instead to dispense with command-line parameters. Instead, every server process in TOS must load and read an initialization file containing any data needed for startup. This violates the very spirit in which the Java interpreter is intended to be used, but was the only effective solution that maintained both platform independence and Macintosh operation.
Impact of UNIX
A Java application written on Windows will run on UNIX with virtually no modification, and TOS is no exception. The only caveat lies in the way UNIX hosts are used. While Windows machines are nearly always accessed directly from the system console, which has full support for the Windows GUI, UNIX machines are often accessed through telnet sessions, under which GUI services are unavailable.
The TOS Administrator is a full-fledged GUI application and thus is simply not supported from a UNIX telnet session; the user must have access to a windowed environment. The rest of TOS, however, uses GUI services only to display error messages.
The most effective way to display an error for a process running in the background is to display a message on the user's screen, which immediately brings it to their attention. On Windows and the Macintosh, this approach continues to be used. When running on a UNIX machine, however, a TOS server checks to see if a windowed display is available when it starts up. If it is, error messages will be displayed in GUI format. If not, they will be written to a command line.
Teaching Suggestions
There is virtually no limit to the enhancements and add-ons that an operating system can have. A list of some possible assignments that could be given in an undergraduate course follows.
- Develop a TOS equivalent of the UNIX talk program, using TOS pipes.
- Using TOS signal objects, write a program that will perform a sequence of actions on several machines in succession, each machine not starting the sequence until the exact moment the previous one has completed.
- Develop a GUI file manager utility to replace the command-line TOS console.
- Add standard clipboard functions (cut, copy, paste) to the TOS editor.
- Add a "merging" feature to TOS, so that two TOS systems can combine, with no loss of disks, sync objects, or pipes.
- Write a program that will display a message on a screen of one computer - but each line must originate from a different computer. The lines must form a readable message.
- Modify the launcher so that if the user does not supply a TCP/IP port number and the default is already in use, the launcher will search for a free port and use it.
- Add support for random-access files.
Bibliography
Anderson, Thomas. "Nachos"
http://www.cs.berkeley.edu/~tea/nachosComer, Douglas
and Munson, Steven.Operating System Design Vol. 1: The Xinu Approach, Macintosh Edition.
Englewood Cliffs: Prentice Hall, 1989.Downing, Troy Bryan. Java RMI: Remote Method Invocation.
New York: IDG Books, 1998.Microsoft Corporation. Microsoft Developer Network Library, July 1998 Edition.
Redmond: Microsoft, 1998.Sinha, Pradeep K. Distributed Operating Systems, Concepts and Design.
Piscataway: IEEE Press, 1997.Sun Microsystems Inc. "Java Platform Documentation"
http://java.sun.com/docs/index.htmlTanenbaum, Andrew S. Modern Operating Systems.
Englewood Cliffs: Prentice Hall, 1992.Vahalla, Uresh. UNIX Internals: The New Frontiers.
Upper Saddle River: Prentice Hall, 1996.


RT @iamdevloper: 1. Load up Google Maps iOS app
2. Find an area you want cached offline
3. Type in "ok maps"
4. Love Google a little bit…
7/2/2014, 11:37:02 PM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @iamdevloper: 1. Load up Google Maps iOS app
2. Find an area you want cached offline
3. Type in "ok maps"
4. Love Google a little bit…
7/2/2014, 11:37:02 PM
Favs: 0
Retweets: 0
link


|
|
H2 Scale and Platform |
x1 |
3-Year |
|
|
Smart Charger for Scale |
x1 |
1-Year |
|
|
Waterproof Storage Case for Scale |
x1 |
Lifetime |
|
|
4" LED Remote Display |
x2 |
2-Year |
|
|
7" LED Remote Display |
x1 |
2-Year |
|
|
Waterproof Storage Case for 7" Remote |
x1 |
Lifetime |
|
|
Display Mounting Hardware |
x4 |
* |
|
|
Heavy Duty Tripod |
x3 |
1-Year |
|
|
Smart Charger for LED Sign |
x3 |
1-Year |
|
|
Wireless Radio Hub |
x1 |
1-Year |
|
|
Commercial Grade Epson Printer and all cables |
x1 |
2-Year |
|
|
Duplicate Copy Printer Paper Roll
|
x5 |
* |
|
|
Waterproof Storage Case for Printer |
x1 |
Lifetime |
|
|
Heavy Duty collapsable baskets |
x3 |
* |
|
|
Basket stabilizer plate |
x1 |
* |
|
|
Owner's Manual
|
x1 |
* |


My name is Jasmine Franklin, I am a developer seeking a position in financial technology. My background is in biological research and business. I possess a B.S in animal science and recently earned a certificate in full-stack web development from UC Berkeley Extension, with recently developed skills in Javascript, Python, and Node.js. I have worked on several research projects within the USDA, one of which resulted in a publication. I also possess experience in finance, economics, and HR. I have a passion for business, I am a problem solver, great communicator, and hardworking.


--- title: Responsive Comping excerpt: '
Responsive Comping: Obtaining Signoff with Mockups, an absolutely brilliant article about #RWD process on @alistapart: http://www.alistapart.com/articles/responsive-comping-obtaining-signoff-with-mockups/
' date: '2012-10-17 15:34:31 +0200' date_gmt: '2012-10-17 13:34:31 +0200' categories: - Webdev ---Responsive Comping: Obtaining Signoff with Mockups, an absolutely brilliant article about #RWD process on @alistapart: http://www.alistapart.com/articles/responsive-comping-obtaining-signoff-with-mockups/.


Ploror688.github.io
Homework help hotline las vegas. Homework Hotline helps students with math. As reported by KSNV-TV, the Clark County School District’s homework assistance program, Las Vegas, NV 89146. Homework help hotline las vegas. Homework Help Online PreKindergarten — Grade 5 Preschoolers can library to read and count, explore animals. Homework help links - Online essay help chat, homework.
Student Enrollment Information Clark County School District.
Campus Portal Parent Information Clark County School. Hamiota, Manitoba, Canada. News Weather Sports Science Shareware Technology Freeware Radio Movies Agriculture Government Tickets Health Banking UberEATS Driver Sign-up Bonus Up to $1,100! Best Promo.
Malcolm in the Middle is a Fox sitcom that ran for seven seasons from January 9, 2000 to May 14, 2006 with 151 episodes produced. The home of all things DEF CON 26, taking place August 9-12, 2018 at Caesars Palace in Las Vegas. Help on Homework: Free Tutoring Need tutor for math and other subjects? Locate free tutoring Las Vegas; free tutors online; homework. Homework hotline las vegas. Homework help dna Cheap Discount. Homework DEF CON® 26 Hacking Conference.
How to write a phd synopsis Homework Help Hotline Las Vegas how to start a college admission essay 5 page hire freelance writers. Student Handbook (PDF) About Highlands University. President’s Letter. Campus Directory. Academic Calendar. First Day of Class/College Life. Chartered Student Clubs. Violencia de Género: un problema que aumenta en la Argentina. Film streaming gratuit HD en VF et VOSTFR, série et manga. All locations have Homework Help Centers and provide what students need to This season on Homework Hotline we will be talking about some important issues. Contact Information. Clark County School District 5100 West Sahara Ave. Las Vegas, NV 89146 USA 702-799-CCSD. Homework hotline las vegas - Big Discount! Paradisul Verde. Faaaala Galera! Acabei de trabalhar na primeira lista de Cinemática. Mando pra vcs agora. Na própria lista marquei quais exercícios tenho, ou em breve terei.
Contests are also a great way for the shyer among us to beat the icebreaker blues and get right into some fun with a bunch of likeminded strangers. Pour télécharger et voir les films en streaming gratuitement sur notre site enregistrer vous gratuitement. Homework hotline number las vegas - Valemour : Valemour.
Chess online games news. play gin rummy, play backgammon, play cribbage, play for money, money prizes, backgammon, cribbage, dominoes, solitaire online. Find Homework Hotline in Las Vegas with Address, Phone number from Yahoo US Local. Includes Homework Hotline Reviews, maps directions to Homework Hotline
Homework help hotline las vegas : Homework help hotline.
Employee General Information Clark County School District. Families New to the Clark County School District Parents of children new to CCSD can use the link below to register. After completing the online registration. Feedback The resources and services on this page are designed to help you understand a variety of issues surrounding brain injury. List of Malcolm in the Middle episodes - Wikipedia.
Homework Hotline in Las Vegas Homework Hotline Homework hotline number las vegas - Essays researches written by top quality writers. Get started with term paper writing and compose finest term paper. W.K. Computing Hamiota Manitoba Canada. Browse our 2019 cruise holidays P O Cruises. Homework Help Las Vegas - Las vegas library homework.
Homework Hotline helps students with math Clark County. To help you more effectively monitor the progress of your child, the Clark County School District provides a web based system. This system will provide detailed Unable to find what you are looking for? This page will help you with your enquiries. Homework Help Hotline Las Vegas. How to Become an UberEats Food Delivery Driver-Best Promo Invite Code 2018; Uber Greenlight Hub Driver Support Office Locations-Search All U.S. Cities and States.
Help on Homework: Free Tutoring - Vegas Family Guide.
.onion Links. defcon.org media.defcon.org defcongroups.org. DEF CON Dates. DEF CON 27 August 8-11, 2019 Paris, Ballys, Planet Hollywood, Las Vegas El aumento de la violencia en la Argentina no se da sólo en las calles, sino que la que viven miles de mujeres diariamente al interior de sus familias, aumenta.


Utilities¶
Graphical output¶
-
CanteraPFR.ct_aux.
plotPFR
()¶ Provide formated plot of results.
Todo
Document keyword arguments.
Parameters: - data (pandas.DataFrame) – Table of integration solution.
- species (dict) – Dictionary of species to plot. Keys must match columns of data and values are used as labels (for allowing LaTeX names).
- saveas (path-like) – Path to graphics file.
- dpi (int, optional) – Output resolution (parsed to pyplot.savefig). Default is 300.
-
CanteraPFR.ct_aux.
plot_adjmatrix
()¶ Plot adjacency matrix of graph.
Todo
Document keyword arguments.
Parameters:
-
CanteraPFR.ct_aux.
plot_deghist
()¶ Plot degrees of graph nodes.
Todo
Document keyword arguments.
Parameters:
Auxiliary methods¶
-
CanteraPFR.ct_aux.
filter_mechanism
()¶ Filter mechanism to contain only selected species.
Read mechanism and remove reactions involving species not required by species list. Transport model if specified must be ‘Multi’. If species is None, the original mechanism is returned.
Note
To date transport model ‘Mix’ has not being implemented.
Parameters: - mech (path-like) – Mechanism file in CTI/XML format.
- species (list of str) – List of required species. Case must match with mechanism.
- transport (str, optional) – Transport model to use. Default is ‘Multi’.
- write (bool, optional) – If True, write XML filtering mechanism.
- idname (str, optional) – Name of new phase. Required if write=True. Default is None.
- output (path-like, optional) – Path to new mechanism. Required if write=True. Default is None.
- overwrite (bool, optional) – If True allows mechanism to be overwritten. Default is False.


--- type: error ---
Sorry, looks like your Internet connection is either out or having trouble connecting and I wasn’t able to cache this page offline before that happened.


…a means of communication
Björn Andersson
stopChan := make(chan bool)
, create a channel<-c
: read from a channelc <-
: write to a channelname <-chan string
: read-onlyname chan<- string
: write-only
greetingChan := make(chan string)
go func (c <-chan string) {
fmt.Printf("Hello, %s", <-c)
}(greetingChan)
greetingChan <- "World"
With channels you can share a limited resource across unlimited concurrency
var dbConns []*DB.Conn // assume it contains 5 connections
dbPool := make(chan *DB.Conn, 5)
for i := 0; i < 5; i++ {
dbPool <-dbConns[i]
}
t.Run("parallel test run 1", func (t *testing.T) {
t.Parallel()
db := <- dbPool
defer func () { dbPool <- db }() // returns to pool
// run lots of tests
})
stopChan := make(chan struct{})
close(stopChan) // No value written to the channel
v, ok := <- stopChan
fmt.Printf("v=%v, open=%v\n", v, ok) // v=false, open=false
v, ok = <- stopChan
fmt.Printf("v=%v, open=%v\n", v, ok) // v=false, open=false
func getMessages(
ctx context.Context,
query Query,
errChan chan<- error,
stopChan <-chan struct{},
) {}
context.Context
means external shutdownerrChan
sounds like there can be errors that forces the function to stop
work on its own
stopChan
tells me that there are other reasons than context to stop
working
select
statementswitch
statement, but for channelsdefault
evaluates immediately if no channel is readable
default


| Display Name | Description | Aircraft | vehicle | location |
|---|
|
Name |
|
|
Description |
|
|
Aircraft |
|
|
Vehicle |
|
|
Comment: |
Your changes will be updated to the spreadsheet.
Please Note: In progress...


odorata species distribution potential climate current area forest models future Cedrela Mexico change increase model used {border-style Climate occurrence px;} scenarios #ffffff;} HADCM Nacional areas data probability carbon average conditions plantations MaxLike presence projected tropical vegetation (±) (±.) Sciences tree CGCM del para records use value COEF Change. based cover different elevation likely mitigation px; suitable {font-family Finally, Forests IEC In: Instituto cedar font-size map polygons regarded study ver. Biology Comisión EMM Ecol Ecological Ecology Fig LRSV. Life Mexico. México. México: Table Tropical double; establishment increasing largest modeling niche pp. presence-only temperature timber using ./j.-...x Available: Cambridge Cambridge, Change GFDLCM Global Mexico, Mitigation Press; ROC Report University Veracruz, adaptation analysis available border-color border-width change. colleagues ecological evergreen forests global growth important increased maps mean methods scenario secondary showed sites solid; statistical suggest variables vectors {font-style {font-weight °'.'' .–, Biodiversity CGC Cambio Change: Current Ecología Environmental Group Grupo However, Information MINDD MMIN MTWM MaxEnt Methods NY, New Potential Science York, [], aVC additional algorithm assess biodiversity bold coast conservation courier; deciduous direction distributions. economic em; environmental estimated forestry general geographic great help high large locations main mitigate mitigation. omission plantation plantations. pt;} red reduce selected slopes sobre soil species.


I'm having trouble with the calibration of the sensor SCT-013. I used the example of openMonitor to samples but the current never 0, the current value is left with 0:07 when without load
I used the resistor 18R and emon1.current (1, 29.41).
Archived Forum |
|
confused with code calibration SCT-013Submitted by andre.luiz1987 on Tue, 28/05/2013 - 03:35I'm having trouble with the calibration of the sensor SCT-013. I used the example of openMonitor to samples but the current never 0, the current value is left with 0:07 when without load I used the resistor 18R and emon1.current (1, 29.41). » |
Re: confused with code calibration SCT-013
You are almost certainly reading noise picked up by the analogue input. This might be power line induced from adjacent wiring, or digital noise coming from the processor itself. See:
http://openenergymonitor.org/emon/buildingblocks/measurement-implication...
http://openenergymonitor.org/emon/emontx/accuracy
http://openenergymonitor.org/emon/node/1385
http://openenergymonitor.org/emon/node/2311
Trystan did some wonderful animated pages a few months ago demonstrating how the errors vary here http://vis.openenergymonitor.org/dev/adc/noiseless, here http://vis.openenergymonitor.org/dev/adc/noisy and here http://vis.openenergymonitor.org/dev/adc/noise.mp4.
Some users have said that connecting a 2.2 nF capacitor from the input pin to ground reduces the noise.
Which current transformer are you using - a calibration of 29.41 is wrong for the -000 version, and a 18 Ω burden resistor is wrong if you are using one of the "voltage output" versions (e.g. the -030) because those already have a built-in burden resistor.
[edited to add more links]
Re: confused with code calibration SCT-013
I’ve built a simple Arduino breadboard test rig to measure voltage and current and have noticed power and current readings when there is none. I checked the analogue value for the CT and it was a constant 510. I understand this is most likely noise and have read the various articles you site, but it strikes me that if the noise is constant? Then it could be removed in the calibration.
In photography when I take a photo with a long exposure, I first take one with the lens cap on and at same exposure as intended. I then have a photo basically of noise which I can subtract digitally from my actual photo. It works better than any gimmicky noise reduction on the camera.
So if you know there is no power then any measurement caused by noise could be removed. Emonlib could be modified to include a calibration constant i.e. y=bx+c. Where b is the normal calibration and c is an offset.
I’m waiting for components to build a variable gain setup and imagine noise will change at each gain level, so it would be great if Emonlb coped with this.
Re: confused with code calibration SCT-013
Thks,
I calmly read what you posted,
As the sensor is Model TCS-013-000, will change the capacitor and resistor Burden.
Re: confused with code calibration SCT-013
No, you need a burden resistor for the SCT - 013 - 000. The 18 Ω burden and a calibration of 111.1 will give you a current range of 0 - 100 A.
[Edit]
To elaborate:
SCT - 013 is a family of current transformers all having the same physical size, but with different maximum currents. All except the 100 A version ( SCT-013-000) have a built-in burden resistor and are classed as "Voltage output" types; the output is 1 V rms at the rated current. The 100 A (-000) version is classed as "Current output" and delivers 50 mA rms at the rated current; this version has protection diodes built in to prevent dangerous voltages appearing if the c.t. is unplugged but they will not prevent damage to the ADC input if the burden becomes open-circuit.


After an article on The Oil Drum I started looking up the energy intensity of different modes of transit. "Energy intensity" is the amount of energy required to do useful work (for instance, to move a passenger).
Here's what I found (from here; chapter 2, Tables 2.11 and 2.12):
Btu/passenger-mile Auto (highway) 3549 1.00 (relative to car; smaller is better) Bus transit 4160 1.17 Bus intercity 932 0.26 Air 3587 1.01 Amtrak 2935 0.83 Rail transit 3228 0.91 Commuter rail 2751 0.78
Public transit also doesn't come off very well from this comparison. Admittedly highway automobile traffic is more efficient than city automobile traffic. But still the energy intensity of public transit is surprisingly bad. This is contrary to most people's intuition; I think this is why people expect public transit to be energy efficient:
One argument for rail or other mass transit is that it uses electrical power. Of course this is not a great environmental benefit now (at the moment it probably compounds the inefficiencies), but in the future it allows for the substitution of more environmentally friendly power generation. It's also strategically advantageous even if we continue to use fossil fuels, because unlike gasoline or diesel there are copious domestic fuels that can be used for generating electricity (like coal).
Then we should also ask: why is public transit so energy inefficient? Yes, it's better than cars, but only barely better. The answer of course is ridership -- if all the trains and buses were full all the time they'd be quite efficient. But they aren't full.
A naive response is that if we just need to encourage more public transit riders: by growing the systems, providing greater operating subsidies, and by taxing or tolling auto traffic. Once ridership is higher the efficiency will go up.
Does that really make sense? Consider some situations:
Why does off-peak service matter? Consider cost: public transit can be quite expensive -- $1.25-$2.00 a trip. Public transit proponents counter that cars are also expensive, but the costs are hidden. This is true, but the incremental cost of a car trip is fairly low. You've already bought the car, have the insurance, and the price of gas is not so high (even now). It's very hard for public transit to compete with the incremental cost of a car trip, except when tolls are very high (as in London) or parking is expensive. Even with parking it can be hard for public transit to compete when there are multiple passengers.
Public transit can only compete with the total cost of a car when it is a real option to actually ditch the car and rely solely on public transit (and perhaps other complementary services like taxis and car shares). If public transit doesn't provide reasonably comprehensive service it can't compete as a primary form of transportation. The complementary services help here, but they can be costly and might not be sufficiently flexible; relying too heavily on those will also cut into public transit's price advantage.
So what's my point? Mostly I feel that these problems need to be considered more honestly by public transportation advocates. But also we are at a point in history where transportation may change substantially; concerns about both peak oil and global warming mean we have to reconsider our current transportation infrastructure. Even without these concerns traffic itself is starting to become a major issue throughout the country, and there are no good near-term solutions; we're seeing substantially diminished returns when building new/larger roads.
What direction will we take going forward? Some are calling for an "Apollo Program" for alternative fuels; a huge, rapid, forceful program to fix our energy problems. Usually what this means is an attempt to switch cars from gas to something else -- usually biofuels, hydrogen or electricity. Traffic may be resolved through automated car lanes. Both kinds of technology are some ways off, but neither seems impossible.
Public transit proponents (and despite my negative tone here, I am one) usually have additional reasons they want public transit. There's a lot of good reasons (though not everyone will agree with all of them):
And more reasons I can't think of now, I'm sure. I want public transit to win over private transit. I just don't think the public transit we have is a very good contender. Maybe we can jam public transit initiatives through the government process once, or twice, or a few times -- but people have already noticed that these initiatives are incredibly expensive and underperform. Retorts that we just haven't tried it on a big enough scale aren't very convincing. Solutions like having the U.S. become Europe or Japan just aren't realistic; the U.S. just isn't any of those places, and just because something works there doesn't mean we can make it work here.
Mass transit today looks a lot like mass transit 75 or 100 years ago. People who believe in the promise of public transit need to demand something more. We need to stop apologizing for poor performing systems. We need to stop pretending it's reasonable to pay $2 to go five blocks, or that a 15mph system is fast enough, or that having to stand during your trip is a great way to meet new people.
What should we do in particular? In my opinion PRT holds more promise than any other system I've seen. Some people disagree, and they should offer up their own plans. But please don't try to just offer the same broken ideas as though they'll work this time. Existing systems (even ones that say they are new) simply aren't good enough.
So city auto "energy intensity" isn't included in that list. A quick survey of the net says that cars are about 30% less efficient when in city traffic. So, that table is now:
Auto (highway) 3549 1.00 (relative to car; smaller is better) Auto (city) 4613 1.3 (car in city traffic) Bus transit 4160 1.17 Bus intercity 932 0.26 Air 3587 1.01 Amtrak 2935 0.83 Rail transit 3228 0.91 Commuter rail 2751 0.78 All those non-car options are looking a little better now. I can see why the report would omit them, give it's angle. Yes, PRT systems look good, but will take a long time to replace the significant existing rail infrastructures we already have. We should still be encouraging people to take public transport over driving their own car.
Thanks for looking up the city energy intensity. Of course, it also assumes that cars have the same number of average passengers -- but honestly I have no idea if it would go up or down for city driving.
I can see why the report would omit them, give it's angle.I don't really think the report has an angle. I do think they have specific data sources, and very possibly none of them covered city driving. I imagine it's much easier to figure out how many cars drive on highways than on city roads, and the other necessary numbers that go with that.
PRT systems look good, but will take a long time to replace the significant existing rail infrastructures we already have.Do they have lots of existing rail infrastructure in Australia? We don't have hardly any for passenger use here. We have freight rail lines, which is what Amtrak also uses outside of the East coast, and that sucks. Much of the rail we have isn't of very high quality, and so it's not particularly fast or reliable to run on.
But PRT doesn't really have to replace existing infrastructure. There's a tremendous amount of in-fill that has to happen, regardless of the system, so there's a lot of new infrastructure that has to be built. Really it's hard to compare the two systems at that point, as no one proposes train systems with coverage anything like PRT systems. Trains simply don't scale that way -- the interchanges are difficult, and changing trains is too slow to have anything like a dense grid. It doesn't work great for Buses, but at least their stations are so cheap (i.e., just a sign) that they can provide good coverage that way. Though both trains and buses have a scaling problem where the speed of the system is slowed down by the number of stops -- so the better your station/stop coverage, the worse your travel time. PRT scales in a completely different way.
Also note that PRT infrastructure is far cheaper than traditional rail because the loads are so much less. Also because there is redundancy in the system it can be deployed incrementally, and repaired or upgraded without total system shutdowns. Rail does not do so well in that case and so repairs become extremely complicated and expensive operations.
# Ian Bicking
One thing that would affect these figures is that US rail is far more energy intensive than the rest of the world. The US idea of a commuter train is often some huge heavy thing with its own specific locomotive, compared to the "bus-on-rails" idea in Europe for example, with an underbody engine. I think the USA could use a fraction of the energy running public transit, if they wanted. Even US buses are much heavier and bigger-engine than European for example. So this would affect these figures..........
If anyone had these kinds of numbers for other countries, that would be awesome.
The US idea of a commuter train is often some huge heavy thing with its own specific locomotive, compared to the "bus-on-rails" idea in Europe for example, with an underbody engine."Transit rail" has an underbody engine, and does worse than commuter rail (though probably for other reasons). I think US transit rail uses essentially the same vehicles as in Europe, but I don't really know.
Even US buses are much heavier and bigger-engine than European for example.For some reason we are very reluctant to run small buses. I'm not sure why; I suspect just to make the fleet more homogeneous, and because like every other kind of transit the people making these decisions don't care about the energy use. People in the US are probably also more tolerant of the size of buses on the street, so there's no pressure to reduce the amount of space they take up.
# Ian Bicking
A big reason US trains are not is efficient is because the US is nuts about safety. Thus US trains are often twice as heavy as European trains in order to make them crash worthy. There are probably many more road-level railway crossings in the US than in Europe. Still, the US is way more strict, and I don't know how effective that really is at preventing accidents. Surely it must lengthen the stopping distance, which would be safer if it could be shorter.
# James
The best way to make our existing transit system work is to increase the density. If you can average to people per car, the efficiency goes up, congestion goes down which also helps efficiency go up. I like the PRT idea but it requires a HUGE investment in infrastructure.
We have plenty of capacity it's just not utilized well. In the morning, there's a wide river of traffic going by my house. I know that many of those people are going close to the same place that I want to go. If there was just some way to link us up, we could share the ride.
I'd like to see a dynamic carpool system. Use the GPS built into the cell phones along with the wireless network to allow people to log in their morning and evening routes. Other people needing a ride would log in their request. I computer would link up riders to available drivers and send directions to the driver to pick them up. I don't carpool now because my schedule is to random. I don't know exactly when I can leave in the evening. With a dynamic carpool, I wouldn't need to. When I'm ready, I just go down to the street and request a ride then wait for the pickup.
This system works best when there's a lot of traffic. Lots of cars increase your chance of finding someone going near to your location. It scales up when you need most capacity and avoids that round trip problem that you mentioned.

Look at the advantages; low or no infrastructure costs, door to door service, 24 hour service cheaper than the other methods. All you need is the software to track drivers and riders over the cell network and send the instructions to link them up. Granted, that software might be difficult to write but I don't think it's impossible.G
Getting people to participate would be the hardest part. You can use the existing carpool programs to encourage ridership. If the system caught on, you could possibly live in a western city without a car.
# Joe Goldthwaite
I like the PRT idea but it requires a HUGE investment in infrastructure.While your car pooling idea requires less (additional) infrastructure, all rail-based transit has much higher infrastructure cost than PRT, and PRT should be cheaper than highway lanes of similar capacity. Of course PRT can't replace the flexibility of roads (which carry things like moving trucks, construction equipment, bikes, ambulances, etc), so it's not really right to compare it to basic road infrastructure (which is inevitably required); but it compares quite favorably to the cost of increasing road capacities. And as an immature technology there's more avenues open to improve it.
While responsive car pooling or taxi service doesn't require new infrastructure (instead increasing the capacity of current infrastructure) the energy intensity improvements seem limited. It would feature smaller vehicles, and by being more responsive and adaptive it could carry a higher number of average passengers. But it still requires vehicles larger than a typical car, and I imagine cars would frequently be running at less than full capacity. I wonder what the energy intensity of a normal taxi is? Probably atrocious -- they frequently drive around with no passengers at all, and tend to use fuel-inefficient vehicles. Ride share systems would certainly be a big improvement over that, and probably buses, but not a huge win. Though by using less vehicles more intensely you can afford to invest more heavily in fuel-saving vehicles or in vehicle upgrades. Anyway, an interesting idea.
# Ian Bicking
I guess the idea isn't new. Here's a paper from 1968;
# Joe Goldthwaite
Ahh yes, but my Hybrid does much better in city traffic than on the highway 58-60 in town vs 48-52 on the highway.
I think transit is a loser for one reason seldom mentioned. No matter how good it is or how dense the neighborhood it is controlled by politics, and that is always inefficient. Also, no matter how good it is, aut travel always offers options and destinations thet transit cannot.
# Ray Hyde
No matter how good it is or how dense the neighborhood it is controlled by politics, and that is always inefficient.This is true of all transit -- road construction is also very political. Anything that involves the public space is political.
# Ian Bicking
Ahh yes, but my Hybrid does much better in city traffic than on the highway 58-60 in town vs 48-52 on the highway.
I think transit is a loser for one reason seldom mentioned. No matter how good it is or how dense the neighborhood it is controlled by politics, and that is always inefficient. Also, no matter how good it is, aut travel always offers options and destinations thet transit cannot.
# Ray Hyde
Cars epitomities rabble individuality, while public transport are like governments. We could do with a system which solves the problem of car pooling, for instance, through social reputation, better interconnectedness and alternatives.
Re suburban culture, I just wanted to point out this article on a recent study that found suburbanites have more friends and are more involved in community: http://www.canada.com/topics/news/national/story.html?id=78c72193-8f5e-4ae3-8b10-e9cc058a8047&k=14483
There's certainly a lot of good things about the suburbs. Lots of the tolerance and diversity of the city are just built on the apathy and indifference of the populace towards each other.
Personally I don't think centralized cities are a good idea -- cities where there's a strong downtown that is the center of activity, and a blending to residential building from that. I'd prefer medium density with lots of room for diverse and eclectic land usage -- on all scales, down to mixed use blocks and buildings. This isn't anti-suburb really, though it is something that traditionally suburbs have outlawed through strict and highly separated zoning.
One of the things I like about PRT is that it's a transit system with no center. People can choose what their center is, and it will likely overlap with other views of the community -- since really there's always a set of overlapping communities, not segmented communities. This can respond much better to self-directed changes in communities over time, and without any overarching plans.
# Ian Bicking
thank you, it is about time a proponant of public transit acknolwledged the problems it has.
# Hank Miller
What about the bicycle?
# Joseph Huang
I have a proposal that you may not have seen...
This is similar to the PRT concepts that have been proposed, except that it REPLACES the automobile. Feedback is welcome...
gary
PRT is only a concept. LRT is a proven success. Here's a video that dispells the myths that PRTistas spin about LRT being "old-fashioned' and ineficient:
http://www.youtube.com/watch?v=e_huq8g8JiQ
Videos about PRT here:
I had the PRT fantasy even before I knew what it was called. It's main problem is the chicken-and-egg 'needs to have world domination before it's successful' issue. It can't build up the way something like EZ-pass did, which needed MUCH less infrastructure. My favorite theory on how mass-transit will evolve is basically that self-navigating/crash-avoiding technologies will evolve and mature at the same time as Japan-like minicar options will become more available near American cities (e.g. Vespas with 4 wheels). Self-navigation will eventually become good enough to navigate huge traffic flows (From a tech perspective, if 802.11s can do it at gigabyte speeds, it can definitely be done at >1millisecond speeds for cars) and most cars by then will be powered by electricity. Then hopefully, all it will take is a couple cities to pay for specialized car/rail connections for continuous power. Then the connections may become available to the population (maybe!).Avidor,
> PRT is only a concept.
Absolutely correct.
> LRT is a proven success.
That really depends on how you define success. We have one in our town, but only a very tiny fraction of the population are in a position to utilize it. It appears empty most of the time. So if you define success as an alternative to the automobile, I would say it fails. The numbers just aren't there.
As for the dumpmarkolson blog, I don't know who Mark Olson is. I've know of J. Edward Anderson, but only vaguely. I have no connection to either one so I'm at a loss to understand you point.
gary