XML

kent logo

CO527 Anonymous Questions and Answers

This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.


Question 101:

I think I have now got my problems with my mailbox implementation down to being something wrong in my `sendmsg' method... Can you let me know if I'm going fatally wrong somewhere here please!

    public static void sendmsg (int source, int destination, int type, Object message)
    {
        [snip code]
    }

Answer 101:

That code looks fine..! I would guess the error is in `recvmsg()'..

Keywords: moss , mailbox


Question 102:

I am having some problems with the `UMailRecv' test. I think the problem is in the `sendmsg()' method. This is my code for it:

    [snip code]

Can you see the problem?

Answer 102:

The code you've given looks mostly fine, except for one thing. In `addMail()', you have the test:

    if (process.pid == pid_from)

This is testing to wake up a receiver, so that test ought to be:

    if (process.pid == pid_to)

There are simpler ways to handle this, however -- there are various anonymous Q+A's relating to this. In brief, it's simpler to just wake up all processes in `sendmsg()', then let them check for messages in `recvmsg()', rather than performing the `pid' test in `sendmsg()' too. (although it reduces the number of needlessly woken processes).

Keywords: moss , mailbox


Question 103:

My question, is just a check really and follows up Question 72 (2003), can you just confirm that we only need to submit our work on `raptor', and not like the course assessments webpage says (Reception) or like the cover sheet says ``Course Administration Office in Computing Reception, The Octagon before 1600 on the deadline date.''

Answer 103:

Yes, just submit on `raptor'; nothing to be handed in at reception. Cover-sheets for this shouldn't really exist, but I think that's part of an automated process (or they had already been `produced')..

Keywords: moss , mailbox


Question 104:

Referring to your answer to Question 88 (2003) -- the second part, how can we tell if something has been signalled by `sendmsg()' or a different process ?

I don't quite understand what this means and how to implement the different scenarios...

``Regardless of whether it was woken up by a signal or by `sendmsg()', `recvmsg()' will return `null'. This is correct if it was woken up by a signal (`current.signalled' is `true'), but not if it was woken up explicitly by `sendmsg()'. In the latter case, it should check the message-queue again and return a message if available -- otherwise it should go back to sleep.''

Answer 104:

The clue was in the answer.. The current process is descheduled using:

    MKernel.schedule ()

When this method-call returns, either it was (1) because the kernel woke the process after receiving a signal; or (2) because your `sendmsg()' code woke it up. You can use the `signalled' attribute/field of the current process to find out whether the process woke up because it was signalled, e.g.:

    MProcess current = MKernel.current[MProcessor.currentCPU()];

    ...
    ...
    MKernel.schedule ()

    if (current.signalled) {
        ... woke up because we got signalled -- remove process from MWaitQueue and return error (null)
    } else {
        ... woken up by "sendmsg()"
    }

You really ought to check for a signal after `MKernel.schedule()' returns, however, the test program should work fine without it (there'll be a small difference in the output, due to the `null' return when woken by a signal, however).

Keywords: moss , mailbox , signal


Question 105:

in response to Question 100 (2003) what does a `synchronized' block do and how do I go about implementing it ?

Answer 105:

A `synchronized' block is a Java language feature that provides mutual-exclusion between threads (it also has other uses). The behaviour and use of `synchronized' was covered in one of last term's lectures -- around the time of the 1st assignment (semaphore implementation or essay).

You don't need to implement a `synchronized' block, you just use it..

Below is a diagram that attempts to show the effect of the code:

    synchronized (X) {
        // critical section
    }

when executed concurrently by 3 threads. Note that the blocking/wakeup here is controlled by Java itself; you do not need any specific code for this. An equivalent alternative (though not as efficient) would be to use one of the MOSS-provided synchronisations, such as the `Semaphore' or `CREWLock'.

Keywords: moss , concurrency , gfx


Question 106:

Should `MMailBox' extend `MProcess' or any other class ?

Also if one process sends another 3 messages, for example, then when the other process calls `recvmsg()', should it only get one of the messages and then another the next time it calls `recvmsg()' and so on ?

Answer 106:

In resposne to your first point, no, `MMailBox' should not extend or implement any class/interface.

As for receiving, yes, each call to `recvmsg()' should return a single message, so if there are 10 messages waiting, the receiver will need to make 10 `recvmsg()' calls to get them all.

Keywords: moss , mailbox


Question 107:

How do we actually make the methods `sendmsg()' and `recvmsg()' (in `MMailBox') into processes ? My two methods look like this, but I guess they need to extend or implement something (such as `MProcess' or `Thread')

    public static int sendmsg (int from_pid, int to_pid, int type, Object message) 
    {
        ...
    }

    public static Object recvmsg (int from_pid, int type, int to_pid)
    {
        ...
    }

Answer 107:

The `MMailBox' class doesn't need to extend/implement anything; neither do its methods. When either `sendmsg()' or `recvmsg()' is called, it is done within the context of a process -- abstracted using an `MProcess' in MOSS. The current process can be found (in code), with:

    MProcess current = MKernel.current[MProcessor.currentCPU()];

This provides the `handle' on the `current' process. For example, to find out the process ID of the process calling `sendmsg()', you can simply look in the `MProcess' structure:

    int my_pid = current.pid;

Keywords: moss , mailbox


Question 108:

Can you tell me how to run the tests on BlueJ or windows ?

Answer 108:

The various tests are run from within MOSS, so you need to run that first. The `main()' method for MOSS is in the class called `MiniOSSim', so from the command line:

java MiniOSSim

or within BlueJ, right-click on the `MiniOSSim' class and select it's `main()' method -- you don't need to give any arguments when prompted.

Once MOSS is running (produces a `MOSS# ' prompt), you can run the mailbox test programs with the command ``run UMailRecv''. The pipe test program can be run with the command ``run UPipeTest''.

Note that the class files for the mailbox tests must be available (they were not part of the original assessment zipfile). If you don't have these tests, see the answer to Question 93 (2003). You'll need to add them to the BlueJ project to ensure that BlueJ compiles them.

Keywords: moss , bluej


Question 109:

What is correct data you should receive from `UPipeTest' when run in MOSS ?

Answer 109:

The standard `UPipeTest', using the existing `MPipe' implementation produces:

    MOSS# run UPipeTest
    process started, PID 3
    UPipeTest -- pipe test..
    UPipeTest: started pipe reader, pid 4
    UPipeTest: wrote 27 bytes, exiting.
    UPipeTest2 -- pipe test (reading half)..
    UPipeTest2: got this [Hello world, down the pipe!]
    child exited with code 0
    MOSS# MInitTask::signal(17) SIGCHLD (pid=4, status=0)

The order in which processes terminate may vary, producing different output. The key things are that the message is received successfully and both processes terminate.

Note that existing test does not test for end-of-file. See the answer to Question 53 (2003) for how to add the two tests you might need.

Keywords: moss , pipe


Question 110:

I have a follow up to Question 95 (2003). My program is currently printing out message 0 once then message 1 three times. This is my `while()' loop that checks for messages:

    [snip code]

Surely the ``mailPool.remove (currentMsg)'' line will remove the message from the pool ?

Answer 110:

In theory, yes. However, `currentMsg' is an object of type `MailMessage', and according to my Java API docs, you can't `.remove' an `Object' from an `ArrayList' -- presumably `mailPool' isn't an `ArrayList' in your code.

As far as the use of `remove()' in your code goes, it looks fine to me. If you still can't get it to work, you can always mail me the code and I'll try and take a look, time and anonymous questions permitting.

Keywords: moss , mailbox


Question 111:

I'm still struggling with `MMailBox' & blocked processes:

  1. The wakeup of all sleeping processes occurs during `MMailBox.sendmsg()' (assuming that I wish to wake all sleeping processes to check the mailstore) ?

  2. The processes are put to sleep in `MMailBox.recvmsg()' ? Or should it be in `MPosixIf.recvmsg()' ?

  3. Is it better to hand in an attempt at blocking that doesn't match the theoretical output of `UMailRecv', or to be able to produce the required output without blocking?

Thanks.

Answer 111:

  1. Yes, the wake-up of blocked processes should be in `MMailBox.sendmsg()'.

  2. The former -- in `MMailBox.recvmsg()'. The reason is that the `MWaitQueue' used to hold blocked receiver processes should be private to `MMailBox'. The code in `MPosixIf' should not be able to access it.

  3. The former, most likely. I'm definitely more interested in seeing correct, or nearly correct, solutions, as opposed to broken solutions that manage to reproduce the sample `UMailRecv' output. `UMailRecv' isn't a particularly sophisticated test..

Keywords: moss , mailbox


Question 112:

Hi. I have this error when trying to test the `send' message, could you explain what it means, or where to start looking to fix it ?

    UMailSend: um, incorrect usage!
    child exited with code 1

Answer 112:

You're not supposed to run `UMailSend' manually! It is started by the `UMailRecv' process automatically. If you look at the code in `UMailRecv.java', you can see where it does this, and what argument is passed.

Keywords: moss , mailbox


Question 113:

What does the method `hasNext()' return if an `ArrayList' is empty ? Do I need to add an extra check, `(isEmpty())' before I actually use the `hasNext()' method ?

Answer 113:

`hasNext()' is a method of an `Iterator', not an `ArrayList'. But if the `ArrayList' were empty, then the associated `Iterator's `hasNext()' method would return `false'. For example:

    ArrayList emptylist = new ArrayList ();

    Iterator it = emptylist.iterator ();

    while (it.hasNext ()) {
        Object item = it.next ();
        ...
    }

In this code, the body of the `while()' loop will never get executed.

For this assignment, however, I think using a `for()' loop instead of an `Iterator' is clearer. For example:

    ArrayList emptylist = new ArrayList ();

    for (int i = 0; i < emptylist.size(); i++) {
        Object item = emptylist.get (i);
        ...
    }

You will not lose marks for using an `Iterator', though.

Keywords: moss


Question 114:

I can now choose to get either:

I can change these options around by changing the following bits of code...

    [snip code]

Can you be more specific at all about what could be causing the program to repeat messages when I am pretty sure that a message is being deleted once read, or hint on how things in the code above should go as it seems to be fairly influential.

Thanks

Answer 114:

I think there are two errors in this code:

Keywords: moss , mailbox


Question 115:

In the extra Moss lecture slides you mention:

    synchronize (local) {
        ...
    }

for the better blocking mechanism.

Can you please explain what the `local' object is referring to again ? And also how to use it in the static `MMailBox' class.

Thanks.

Answer 115:

The `local' `object' in the slides is referring to some `local' (in the sense of `private' to the class) object that acts as a lock.

In the `MMailBox' class, there will likely be two things that need protecting from race-hazards: the message queue/array/list and the blocked-processes `MWaitQueue'. You could substitute either of these for `local', since they are visible to all threads. Personally, I'm not a huge fan of re-using an existing attribute/field for use with `synchronized', unless there is only one such attribute/field. If you look around other bits of MOSS, you'll see code such as:

    public class MThing
    {
        private static ArrayList some_things;
        private static MWaitQueue blocked;

        private static Object synclock;             // to protect the above

        ...
    }

The typical usage of this is:

    synchronized (synclock) {
        ... do stuff to "some_things" and "blocked"
    }

You must initialise, the `synclock' though -- i.e. ``synclock = new Object()'' with your existing initialisation.

Keywords: moss

Referrers: Question 116 (2003)


Question 116:

So far, I have managed to implement the `mailbox' successfully. However, I am still really stuck on trying to work out how to get the process running `recvmsg()' off of the wait-queue and running again. I think I saw an answer to another anonymous question in which you stated that this should be done in `sendmsg()'. However, another question stated that `MPosixIf' should not contain an `MWaitQueue'.

Currently, I'm considering putting a ``private static MWaitQueue'' in `MMailBox' and having ``public static synchronized'' methods to add-to, get-from and delete-from the queue, to be called from `sendmsg()' and `recvmsg()'. I'm not sure if this is the correct approach.

Answer 116:

The first question you refer to was talking about a `sendmsg()' in `MMailBox' -- it's not unreasonable to use the same method names.

Your thought about having a `private static MWaitQueue' in `MMailBox' is correct. Having `synchronized' methods is probably not the way forward, though. `synchronised' methods are like `synchronised' blocks on the `this' object. However, a `static' method has no `this', thus the effect of a ``static synchronized'' method is un-clear. The answer to Question 115 (2003) might be of some use here.

Keywords: moss , mailbox


Question 117:

Hi, I can't get passed this stage:

    MOSS# run UMailRecv
    process started, PID 3
    UMailRecv -- mail-box receiver process
    UMailRecv: started message sender, pid 4
    UMailSend -- mail-box sender process
    UMailSend: sending sleepy messages to PID 3...
    UMailSend: done.  exiting.

Where am I going wrong or where do I start to try and fix it?

Answer 117:

It looks like the `UMailRecv' process goes to sleep and never wakes up. This means that either the code for `recvmsg()' is putting the process to sleep incorrectly, or the wake-up code in `sendmsg()' isn't waking-up the blocked receiver correctly.

Keywords: moss , mailbox


Question 118:

I was reading some notes and was wondering what does indivisible mean in the sentence:

``implementation of semaphore operations requires indivisible access to memory''

Answer 118:

`Indivisible' means, literally, ``cannot be divided''. For memory access, it means that an operation cannot be `broken' (divided). Basic memory operations (from the processor's point of view) are things like `read' and `write' -- generally between processor registers and memory. `Read' and `write' instructions are typically indivisible.

For example, assuming there is a place in memory called `x', and one processor does `x = 42;' and another processor, at the same time, does `x = 99;', then the value of `x' (in memory) will either be 42 or 99; what it won't be is some blending of the bits.

`Increment' and `decrement' are two other, slightly more complex, operations -- and ``indivisibility'' becomes an issue. `Increment' is effectively `read -> add 1 -> write', whilst `decrement' is `read -> sub 1 -> write'. When executed by two thread/processes on two separate processors, the result could end up being `wrong'; e.g. if both processors attempt to increment some `x', the end result might only be `x+1' instead of the more correct `x+2'. If the `increment' instruction is `indivisible', however, the outcome will always be `x+2'. Instructions that operate on memory in an `indivisible' manner are said to be atomic. Some processors provide `atomic' increment/decrement, others do not.

One example given in the notes is an instruction of the form:

    xchgl %eax, lock

This swaps the contents of the `eax' processor-register with the `lock' value in memory, atomically. This too is a non-trivial operation, since it involves both a read and a write on the same memory location.

Keywords: indivisible , atomic


Question 119:

I was looking at the first quesiton of the 2002 CO501 paper and it asked how I would write a formatting program. I don't really know how I would answer this. Would I talk about the different filing systems?

Answer 119:

No, talking about different filing-systems is not what this question is after, although you might mention others (or rather their respective formatting programs) for comparison. This question is asking how you would write a formatting program -- for some known file-system, disk size (1 - 100 GB), and disk geometry (heads/sectors/tracks).

You have to describe how a formatting program, that you might write, would work. The job of a formatting program is to lay out the on-disk structures required by the filing-system.

A good starting-point for the answer could be: ``Firstly, the formatting program will interrogate the disk to discover its geometry, then perform a read/write test of each sector/track, building a bitmap of any tracks containing bad sectors. This `track bitmap' is then written to the disk itself to indicate what areas of the disk are usable. Next, a `superblock' is created and written to the disk, describing the size and geometry of the disk, as well as a the `logical block' location of the file-system root.''

And it could go from there... You might elaborate on that early part, by writing the track-bitmap and `superblock' multiple times in multiple places, so that if one copy gets destroyed, others are available.

Following on from that, you would probably want to talk about logical-block organisation -- i.e. how the mapping from logical to physical addressing works. There is scope for some cleverness here, given that the drive geometry is known. This might be a pure OS thing, however -- e.g. C-SCAN disk-optimisation algorithm, etc., but is probably worth mentioning.

Other things that you might talk about are creating/initialising free block-lists, replicating certain information (maybe directories, or specially tagged files), etc.

Keywords: exams , formatting


Question 120:

Just two questions both from past papers. I ask these as I'm not exactly sure what is required in the answer.

2003 (4a): do we just need to describe that message passing has two primitive operations and discuss blocking and non-blocking receive as well as that over a network it can be buffered and non-buffered as well as any advantages and disadvantages?

2002 (4c): would we just describe and expand upon signal and wait procedures as well as describing a spinlock as well as its associated advantages and disadvantages. Also is there any need to discuss the difference between counting and binary semaphores?

Thanks for any answer.

Answer 120:

For question (4a) 2003, yes, you would be expected to describe the `send' and `receive' operations, including blocking/non-blocking and buffered/non-buffered operation. Buffering, or a lack of it, does not require a network, however. Giving a couple of simple examples of using message-passing as a communication primitive, with advantages and disadvantages, would gain more marks than just describing the operations and implementations.

For question (4c) 2002, you are asked to discuss implementation aspects of the semaphore, so just describing the signal/wait operations and a spinlock is not enough. A `complete' answer would describe the semaphore operations in terms of their implementation, including how and why the spinlock is used. There is no real need to discuss the difference between a `counting' and `binary' semaphore, however. A `counting' semaphore is just an ordinary `Dijkstra' semaphore, and a `binary' semaphore is just a special-case of this (i.e. the value is only ever 0 or 1).

Keywords: exams

Valid CSS!

Valid XHTML 1.0!

Maintained by Fred Barnes, last modified Thu May 8 12:58:05 2014