you will be implementing a virtual machine threading API in either C or C++. Your virtual machine will be tested on the CSIF machines.

INSTRUCTIONS TO CANDIDATES

ANSWER ALL QUESTIONS

You will be working alone for this project. This specification is subject to change at anytime for additional clarification. For this project, you will be implementing a virtual machine threading API in either C or C++. Your virtual machine will be tested on the CSIF machines. You must submit the provided source code (including apps), your source files, readme and Makefile in a tgz file.

You will be provided a machine abstraction upon which you will be building the thread scheduler. The virtual machine will load the “applications” from shared objects that implement the VMMain function. The virtual machine will need to support multiple user space preemptive threads. Threads at the same priority level will time share with a quantum of one tick. The virtual machine file access is provided through the file API. Threads have three priority levels low, medium, and high. Threads are created in the dead state and have and have state transitions as shown below.

1. I/O, acquire mutex or timeout    
2. Scheduler selects process      
3. Process quantum up    
4. Process terminates      
5. Process activated    
6. Process blocks  

A makefile has been provided that compiles the virtual machine as long as you provide your code as VirtualMachine.c or VirtualMachine.cpp. Do not modify any of the other files, just create your VirtualMachine.c or VirtualMachine.cpp file. It will create the virtual machine call vm. The applications can be built by making the apps with make apps. New apps can be built by adding a C or C++ file in the apps directory and adding $(BINDIR)/filename.so to the Makefile apps line dependencies.

You will be adding to the virtual machine a mutex API which provides a synchronization mechanism.

The MachineFileRead and MachineFileWrite functions require that shared memory locations be used to transfer data to/from the machine. In addition the maximum amount of data transferred must be limited to 512 bytes. VMFileRead and VMFileWrite must still be able to transfer up any number of bytes specified.

The vm syntax is vm [options] appname [appargs]. The possible options for vm are -t, and -s; -t specifies the tick time in millisecond, and -s specifies the size of the shared memory used between the virtual machine and machine. By default the tick time is set to 10ms, for debugging purposes you can increase these values to slow the running of the vm. The size of the shared memory is 16KiB. When specifying the application name the ./ should be prepended otherwise vm may fail to load the shared object file.

The machine layer is implemented using a cooperative process that communicates using the System V message queues. As such during your development your program may crash prior to the closing of the message queues. In order to determine the message queue id, you can use the ipcs command from the shell. You can remove the message queue with a call to ipcrm. You can read more about the System V IPC commands at: http://man7.org/linux/man-pages/man1/ipcs.1.html http://man7.org/linux/man-pages/man1/ipcrm.1.html

The function specifications for both the virtual machine and machine are provided in the subsequent pages.

You should avoid using existing source code as a primer that is currently available on the Internet. You must specify in your readme file any sources of code that you have viewed to help you complete this project.

Helpful Hints 

• Create a VirtualMachine.c or VirtualMachine.cpp file and include VirtualMachine.h
• If your code is in VirtualMachine.cpp, you need to enclose all of your functions in extern "C" {}. For example it might look like:

#include "VirtualMachine.h" extern "C"{

TVMStatus VMStart(int tickms, int argc, char *argv[]){

}

...

TVMStatus VMFileWrite(int filedescriptor, void *data, int *length){

...

}

 

}

• You should probably get the applications working in the following order: so, sleep.so, thread.so, file.so, and then preempt.so. File might be able to be done sooner but may need to be revisited once threads are added if done after hello.so.

 

• The VMStart and VMFileWrite functions will be the first you will want to write.

• You will want to use a skeleton function to be the initial entry point for the thread, and for it to call the entry from the VMThreadCreate. This is necessary in case the thread doesn’t explicitly call VMThreadTerminate.
• Disabling signals with MachineSuspendSignals and resuming them with MachineResumeSignals is similar to disabling and resuming interrupts and can provide mutual exclusion during the execution of critical code. This pair of functions can be safely nested without loss of mutual exclusion in the outer set.
• Don’t forget to enable signals with MachineEnableSignals before calling the

VMMain app entry point.

• You will need to use the volatile keyword for variables that may get modified during a signal handler. The volatile keyword guarantees that the compiler will generate code to go to memory for every access of the variable.

• You will likely want an idle thread that will execute when all other threads are blocked. Conveniently the thread priorities are set to HIGH, NORMAL, and LOW as 3, 2, 1, so a lower priority could be used for IDLE.

• It may seem intuitive to initialize the SMachineContext in VMThreadCreate with MachineContextCreate; however, you will run into difficulties with reactivating dead threads if not done in VMThreadActivate.

• Remember that when MachineContextSwitch is called the context is switched, so the function will not return until the context is switched back. You will need to update global and local variables before switching contexts.

• Each Mutex will probably need their own wait queues similar to the ready queues

When updating the machine interface, you may want to use a wait queue similar to that of your mutex. It may be possible that the amount of shared memory available has been used up by all of the other threads

• In order to simplify the Machine file interaction, you could allocate sections of the shared memory into 512B chunks. This is the largest allowed for a single transfer and will simplify bookkeeping for allocated vs free space.

• Two new apps badprogram.so and badprogram2.so attempt to test the VM API by passing in invalid parameters. These are good tests to make sure you can pass.

Beginning VMStart

At the very beginning to get hello.so working you will want your VMStart to do the following in order:

1. Load the module with VMLoad that is specified by argv[0].
2. Initialize the machine with MachineInitialize.
3. Enable signals with MachineEnableSignals.
4. Call the VMMain entry point.

5. Terminate the machine with MachineTerminate.
6. Unload the module with VMUnloadModule.
7. Return from VMStart.

As you add more functionality you will be inserting more code at various points in VMStart

Attachments:

Related Questions

. Introgramming & Unix Fall 2018, CRN 44882, Oakland University Homework Assignment 6 - Using Arrays and Functions in C

DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma

. The standard path finding involves finding the (shortest) path from an origin to a destination, typically on a map. This is an

Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t

. Develop a program to emulate a purchase transaction at a retail store. This program will have two classes, a LineItem class and a Transaction class. The LineItem class will represent an individual

Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th

. SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of Sea Ports. Here are the classes and their instance variables we wish to define:

1 Project 1 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of

. Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of Sea Ports. Here are the classes and their instance variables we wish to define:

1 Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of