This class wiki serves as both a blackboard for technical discussions and a billboard for information sharing. The organization of this wiki is made as simple as possible but hopefully also effective enough for discussion and Q&A. In general, postings go to one of the four sections below. The Announcements is basically used for reminding students of the class schedule and homework due dates. The on Administration is where you put questions about class administration, for instance, about grading criteria. The other two sections are the places for technical discussions. All the specific questions and issues about the assignments go to on Assignments. The other general questions and comments about the course content go to on Technical Content.

Following a good twiki style, every posting should better be tagged with the author name and the posting time.

Access Control

Class Website

Announcements

Assignment 1 due date: 2/1. Please use the turnin script on the graduate network to turn in your homework. Note: For some technical reason I haven't been granted access to the cs458 account yet. To turn in the the first part of the assignment 1, which is due on 1/28, please send emails to me directly. Sorry about the inconvenience. -- TongxinBai 27 Jan 2008 The turnin script is up now. -- TongxinBai 28 Jan 2008

on Administration

on Assignments

I recommend taking a look at /usr/grads/share when you're setting up your account on sync. I've installed, and am technically the maintainer of, up-to-date development tools for sync and swym. You should set your paths to use the current versions of applications as installed. There's no need to reinstall them yourself.

As a side note, the assignment 1 page recommends lung as a single-processor SPARC to test your code on. Keep in mind that lung is Solaris 8 (probably in v8plus mode) and sync is Solaris 10 (I think it's in v9 mode), so you're likely to need different compiler flags on the different architectures if you're doing anything interesting. Lung also mounts the NFS file system so you need to make sure that your .bashrc and .cshrc don't try and do anything funny with a non-SPARC binary when you log in, or you'll wind up with errors.

The installed tools are probably different versions as well, come to think of it. Maybe it's not such a great idea to use the modern tools on sync if you're going to be developing on lung... anyone else's comments are welcome.

I guess Michael's intention was to use a pdf to show performance data in a graphical manner. In that sense a PDF README is preferred, otherwise you have to include another PDF file for your result evaluation.

Another useful feature that can help with building on different environments is OS = $(shell gcc -dumpmachine | sed -e 's/.*-//' -e 's/[0-9].*//'). If you stick this in your Makefile you can figure out what operating system you are running on and make appropriate paths and things.

It's been noticed that last night someone used the machine for an enormous amount of time causing other people had to wait overnight until they could start their tests. Since our resources are limited and shared, please be considerate and take good control of the time when you are about to launch any testing.

Minor question: When it says, "have each thread run a loop in which it repeatedly enqueues data to, or dequeues from (with 50-50 probability), a shared queue", does that mean that each thread should (for every iteration) flip a coin and decide whether to enqueue/dequeue this time, or should there be a 50% chance on spawning each thread that it is either an always-enqueue or always-dequeue thread? I wasn't sure how to read that "50-50". Thanks.

Based on the paragraph that follows the list of queue types it's the coin-flip style (otherwise there would be no reason to "preallocate" random numbers, and the "preallocation" of nodes would also be odd if a thread is always dequeueing).

An issue that arises is how to deal with an empty queue. The easiest solution is to just fail the dequeue and go on and do whatever your next coinflip tells you to do. The problem with this approach is that this means that in the long run you're going to be enqueueing slightly more often than you dequeue, which will lead to an overall growth trend in the queue. You could precisely compute the probability of dequeueing from an empty queue for any particular insert and adjust your priority accordingly. You could have one "enqueue only" thread but that's going to change the kind of performance that you see. You could just take the easy approach, which is what I'm doing.

As a side note, an alternative to preallocating random bits, which can take up a lot of space and cause strange cache behavior, is to use rand_r which is a reentrant rand call that is thread safe. Also in this case it's possible that a thread can run out of local nodes. It makes sense to allocate another block of local nodes rather than waiting for a dequeue to become available.

So if you have counted_ptr<Node> head; you can say if (head.ptr == NULL) and you can also say casX(&head.ull_for_casx_or_mvx, ...). This avoids explicit casting and makes code easier to figure out. If you're using C++ you can also give the union or struct members like T* operator->() or nice constructors to make it easier and safer to use.

As a side note, you should be able to template the union version directly, but I can't seem to get g++ to like it when I do. Hope this helps someone.

Assignment 2

There is a question raised about the input format. For the convenience of testing and grading your program is supposed to take inputs from stdin to which I can redirect my test input sets when I test your program. The input format is described in the web page, the first line indicating the number of cities with the following lines giving out the coordinates.