In lecture we learned that POSIX threads or ``pthreads'' are intended to be a standardized and portable thread API. Of course, our world is far from ideal and there are always some differences even among standardized entities.
Sun's Solaris implements pthreads on top of native Solaris threads. Both APIs are well-documented. It's worth noting that threading in Solaris follows the so-called ``M:N'' model, where M is the number of kernel threads per process and N is the number of user threads per process. You can read what Sun has to say about the subject, but to be brief, Solaris multiplexes N user threads on top of M kernel threads (M may be one) unless the programmer overrides things by setting the appropriate scope attribute. If PTHREAD_SCOPE_SYSTEM is set, Solaris is forced to a 1:1 model with each user thread running on its own kernel thread. Sun's Multithreaded Programming Guide covers most of the gory details. If you want to know how Solaris deals with blocking system calls in user-level threads, you can check this out.
Linux, at least at this point in time, is different. Linux pthreads always follow a 1:1 model where each user thread corresponds to a kernel-level thread. In fact, Linux threads are implemented using the clone() system call and actually appear as distinct processes! When it is released, the 2.6 kernel will contain a new pthreads implementation ( see also this paper) which is much more POSIX-compliant than the current ``LinuxThreads'' implementation. A group has also developed a M:N pthreads library for Linux but they seem to have lost the popularity battle and have frozen development.
The 2.6 kernel, though, is still in development and pthreads for Linux (2.0, 2.2, and 2.4 versions) are currently implemented by the quintessentially Gallic LinuxThreads library. LinuxThreads almost, but not quite, implements the POSIX 1003.1c thread standard. In particular, signal handling under LinuxThreads is not POSIX-compliant. Read the documentation carefully.
Matrix File Format
Be sure to read the matrix file format specification carefully. Our file format is not the one you might expect. Any FORTRAN hackers in the class will feel at home, though.
We are using row-major indexing. Elements of the matrix are specified as m[rn,cn] where cn == column number and rn == row number. Assuming this indexing, the specification begins to make sense:
num_matrices Name1 row_dimension col_dimension m[0,0] m[0,1] m[0,2] ... m[1,0] m[1,1] m[1,2] ... ... Name2 row_dimension col_dimension m[0,0] m[0,1] m[0,2] ... m[1,0] m[1,1] m[1,2] ... ...
All the elements of row 0 are listed first, then all the elements of row 1, etc. The example generation program generates what LOOKS like the transpose of what one expects:
$ rand_matrix -r 1 -c 3 1 3 84.0188 39.4383 78.3099
The rows extend horizantally