Joel's Blog

Regarding the project for the fall SDBS class in ITU of 2010.  I will list some resources that I found that could be helpful in completing the PCM part of the project (Question 2).  Though most of my list refers specifically to PCM, the file system and the operating system; I think the context given by these documents can potentially help in answering other questions in the project.

1. The first Google hits are usually Wikipedia pages. Comments like “PRAM can offer much higher performance in applications where writing quickly is important, both because the memory element can be switched more quickly, and also because single bits may be changed to either 1 or 0 without needing to first erase an entire block of cells.” are relevant.  The whole “PRAM vs. Flash” section is giving a list of characteristics
2. Numonyx is one of the pioneers of PCM.  Here is a cool video that contains an introduction to PCM.
3. Cool article containing information about PCM.  While reading it you might also want to check out the referenced articles.
4. A paper talking about how to design a File System for PCM.  This one has lots of ideas and clarified key concepts when I read it.
5. A paper talking about characteristics of PCM.
6. A paper talking about PCM & main memory.

Note that for 5 & 6 you need to download the pdf from the ACM digital library.  This might not work if you are not using the ITU network.  Hope this increases the helps some people.

The IT University of Copenhagen has this printing system where you have a centralized server receiving all the printing requests.  I was having a hard time finding the way to configure my Fedora to talk to this server.  A colleague showed me that one can configure CUPS to talk Samba.  And coincidently, the ITU servers spoke fluent Samba.  Here is my procedure on how to configure the printing service in ITU:

Black and White printers:
1. Make sure you have CUPS installed.  Go to http://www.cups.org/ if in doubt.
2. Connect to your CUPS by going to http://localhost:631/
3. Administration -> AddPrinter
4. Select “Windows Printer via SAMBA” and hit “continue”.
5. Type the following in the “connection” text area:
“smb://YOURUSERNAME:YOURUSERPASSWORD@DOMAIN/printsrv/print”
Replace YOURUSERNAME with your itu user name
Replace YOURUSERPASSWORD with you itu password
DOMAIN is not replaced.
Note that there is a colon “:” in between the user name and the user password.
Hit “continue” after typing all this.
6. Choose a name I used “Black&White” and hit “continue”.  The description and location are not important.
7. Instead of choosing a printer you will provide a PDD file.  Search for the cnir23u1.ppd on your system and hit “add printer” and hit “continue”
8. And you are done.  Enjoy :) you should see the printer you just created when you try to print stuff from other apps like openoffice and epdfview.

Color Printers
Repeat the same steps as for the black and white printers.  But instead of “smb://YOURUSERNAME:YOURUSERPASSWORD@DOMAIN/printsrv/print” use “smb://YOURUSERNAME:YOURUSERPASSWORD@DOMAIN/printsrv/colourprint”.  Also make sure you use the correct PDD file.  The correct file is at cnrc322u1.ppd.gz.
If you have any issues email jogr@itu.dk.



While doing some more problems I noticed some more little issues that I want to get down before I forget:

1. There is a misspell on page 282 in the before last paragraph, second line.  It says “flip-flip” when it’s supposed to be “flip-flop”.
2. The code on page 456 (the read_input procedure) has strange indentation.  There is a while statement on line 32 that just does not make sense.  Note that this line was changed from the original implementation of read_input on page 454.   It appears that the change involved removing the “nothing” and adding a body to the while.  Unfortunately the body was added without any indentation.  IMO the body of the while in line 32 is made up of line 33 and 34.  Additionally from the strange indentation in lines 33 and 34, we have also strange indentation in lines 35 and 36.  These lines appear to be outside of the “do forever” loop.  Note that they were originally inside the “do forever” loop.  Based on the answers to problem 10 I think that these lines are also missing an indentation to the right.  In any case this part of the problem requires a review.
3. Problem 10.10.C in page 458 asks about deadlocks in the code.  I agree with the answers given by the answer sheet, but I do not agree with the explanation.  Let me explain:  The answers states that “if the interrupt occurs between statements 35 and 36 of read_input, then the interrupt handler will set input available just before read_input resets it, and read_input will loop for ever waiting for input_available to become true.”  I don’t agree with the explanation because if the interrupt occurs between lines 35 and 36, the procedure DEVICE(n) is executed with input_available[n]=true.  And on the second line of the DEVICE(n) procedure, it would lock because the input_available[n] would never be false.  In other words it would lock in the DEVICE procedure, not in the read_input procedure.  Am I missing something?
4. Similarly on problem 10.10.A the answer states that “If device 0 interrupts thread 0 after it checks input_available but before it gets to the statement in YIELD that changes its state to WAIT, the interrupt handler will run and call NOTIFY, then YIELD will set the thread’s state to WAIT, where it will remain forever, because it missed the NOTIFY”.  I agree that it misses the notify and there is a race condition, but I don’t agree with the word “forever”.  It will stay in this state until the next run of DEVICE(n).  Remember that DEVICE is an interrupt handler and that interrupts are only disabled inside DEVICE.  Am I missing something?

That is all I got for my second batch :)

Update 22-11-2010: My advisor made me realize that there is a deadlock for problem 10.10.A.  The deadlock occurs on a subsequent call to DEVICE.  It occurs when the thread is in wait state.  The thing to notice here is that the second call to DEVICE finds the input_available[n] variable set to true (because thread n missed the notify); this will cause the DEVICE interrupt handler to deadlock. :)

This semester I was TA in a class called Building Database systems, Taught by Philippe Bonnet.  The class had a strong systems design focus and the book that was used was Principles of Computer System Desing by Jerome H. Saltzer and M. Frans Kaashoek.  In general I enjoyed the book.  I think it has a unique and simple way of explaining key concepts in computer system design.  With that said, I had some issues regarding some of the problems in the book.  In general they were related with the consistency of the problem texts.  This post is a list of the ones that I can remember.  I’m not going to go very deep into the contents of the specific sections as I assume that you will buy/get the book if you are interested.

1. Problem 2 (page 428):  Question 2.1.B asks if “the insert RPC stub on the Web server sometimes returns OK without inserting the triple into the storage system”.  Additionally the insert procedure is described as “adds the triple to the TSS if it is not already there and returns OK”.   I think that this description fails to properly distinguish two things: first, when there is no triplet in the TSS and the RPC call fails to insert one; and second, when there is a triplet in the TSS and the call to insert the same triplet does not insert it because it’s already there.  In this particular question this difference is very important because the answer changes depending on which you mean.  If you are referring to the first one, then the answer is probably that 2.1.B is not seen.  On the other hand if you are referring to the second one, then the answer is probably that 2.1.B is seen.  (2.2.B has the same inconsistency)
2. Problem 7 (page 443):  There are some inconsistencies with the way the transfer block is handled throughout the problem.  In the beginning (page443:4th paragraph) we are presented transfer as a block of memory and both the client and the service map to that address block.  In the description of init_service we are again told that transfer is a block since it is called with the allocate_block function (Page 248 refers to allocate_block as returning the physical address of the block).  The problem description continues to say “… copies the LRPC into the transfer page. …”; This passage hints that transfer is not a block and in fact is a page that needs to be translated into a block (page:246 numeral 1,2).  On the same paragraph it continues to say “… writes the result parameters in the transfer block and transfers…”; this adds to the inconsistency referring to transfer as a block again.  Finally en the 7.2 question on page 445 it asks “For the LRPC to work correctly, must the two virtual address transfer have the same value….”; this again refers to transfer as a virtual address adding to the inconsistency.  My intuition here is that transfer is a block and should be referred to as a block through out all the problem 7.7.
3. The answer to 7.7.A (page 446) requires making assumptions about receive, but the problem states that “(the code for the procedure at the address receive is not shown because it is not important for the questions)”, which hints at the answer being in another place.  The question is inconsistent in telling you that you shouldn’t look for answers in receive, when in fact one of the answers is there.  Notice that this also happens with 7.7.{B,C,D} but to a lesser degree.
4. The answer to 7.7.A (page 446) requires assuming that receive copies whatever is in transfer to its private address space.  But in the problem there is no place where this assumption is hinted at.  Note that Return_LRPC copying the return statement from receive from transfer says absolutely nothing about how transfer is implemented.

These 4 are the ones that I have fresh in my memory :)