Pthreads Overview

Here's a quick overview of the calls available to a programmer using Pthreads (both the standard Pthreads API and GNU extensions). It's intended to be as brief as possible while being (i) descriptive and (ii) not just a list of all the available calls. The links are to the relevant man pages on linux.die.net.

Note: The "NP" at the end of certain functions and macros stands for "non-portable". They are GNU extensions, accessed by e.g. #define-ing _GNU_SOURCE.

• Thread creation and attributes
• Thread operations
• Fork/thread termination handlers
• Thread termination and cancellation
• Signal operations
• Scheduling and CPU time/affinity
• Thread-specific data and one-time-only operations
• Locking mechanisms
• Mutexes
• Read/write locks
• Spin locks
• Memory barriers
• Condition variables

Thread creation and attributes

A thread is created with pthread_create(). Thread attributes can be specified when it is created with a pthread_attr_t structure, which gets initialized with pthread_attr_init() and destroyed with pthread_attr_destroy(). A copy of a thread's current attributes can be obtained with the GNU-specific pthread_getattr_np().

The pthread_attr_t can have the following operations performed on it:

• The thread's initial CPU affinity mask can be accessed/modified with pthread_attr_getaffinity_np() and pthread_attr_setaffinity_np().
• Whether the thread is detached or joinable can be accessed/modified with pthread_attr_getdetachstate() and pthread_attr_setdetachstate().
• The size of the guard area (area at the end of the stack that will generate a segmentation fault on access, to detect stack overflow) can be accessed/modified with pthread_attr_getguardsize() and pthread_attr_setguardsize() (but note that guard sizes are rounded up to page boundaries when applied).
• Whether the thread gets its scheduling policy and parameters (see the next two points) by inheriting them from the current thread or explicitly from the values set in the attribute structure can be accessed/modified with pthread_attr_getinheritsched() and pthread_attr_setinheritsched().
• The scheduling policy the new thread starts with (assuming it's been set to have this explicitly specified; see above) can be accessed/modified with pthread_attr_getschedpolicy() and pthread_attr_setschedpolicy().
• The scheduling parameters (i.e. priority, unless more parameters are added in future) the new thread starts with (assuming it's been set to have this explicitly specified; see above) can be accessed/modified with pthread_attr_getschedparam() and pthread_attr_setschedparam().
• Note: Only system-level contention is available on Linux. Whether the scheduling contention scope of the thread is at system-level (i.e. the thread's priority is compared with every other thread on the system when allocating CPU time) or process-level (i.e. the thread's priority is only compared with other threads in the process; the process itself must get CPU time before the scheduler decides if the thread deserves CPU time) can be accessed/modified by pthread_attr_getscope() and pthread_attr_setscope().
• If a thread needs to run with a stack with a specific location and size, this can be accessed/modified with pthread_attr_getstack() and pthread_attr_setstack(). The size alone can be accessed/modified with pthread_attr_getstacksize() and pthread_attr_setstacksize(). (The functions for accessing and modifying the address are pthread_attr_getstackaddr() and pthread_attr_setstackaddr(), but they are obsolete).

Thread operations

A thread can get its own ID via pthread_self(). Two thread IDs can be tested to see if they refer to the same thread with pthread_equal() (don't just use ==).

Fork/thread termination handlers

You can specify functions to be executed immediately before and after a call to fork() (in both parent and child) with pthread_atfork(). This is useful in e.g. a threaded library, since the child process a fork() creates only consists of a single thread.

Thread clean-up handlers (analogous to atexit()/on_exit()) can be registered/unregistered with pthread_cleanup_push() and pthread_cleanup_pop(). They will be called if the thread is cancelled or it exits using pthread_exit() (but not if it just returns from the thread routine).

If you're worried about asynchronous cancellation between pushing/popping clean-up handlers (and who isn't!) you can use the GNU-specific pthread_cleanup_push_defer_np() and pthread_cleanup_pop_restore_np() instead, which (i) set the thread cancellation type to deferred (see Thread termination) and (ii) restore the previous thread cancellation type, respectively.

Thread termination and cancellation

A thread can exit from a thread at any time using pthread_exit().

A thread that is joinable can be joined with pthread_join(), which will block until the thread has finished. A thread can be moved to the detached state with pthread_detach() (the reverse cannot be done). Normally, an attempt to join will block until the thread has finished, but this blocking behaviour can be avoided with the GNU-specific pthread_tryjoin_np() and pthread_timedjoin_np().

One primitive way of terminating a thread is to cancel it with pthread_cancel(). Whether the thread is able to be cancelled in this way can be controlled with pthread_setcancelstate(), and whether such a cancellation is deferred or delivered at a cancellation point can be controlled with pthread_setcanceltype(). Within a thread, an "artificial" cancellation point can be generated by calling pthread_testcancel().

Signal operations

A signal can be sent to a specific thread using pthread_kill() or pthread_sigqueue(), analogous to the normal kill() and sigqueue functions.

If you're using LinuxThreads (you'll probably know if you are; most systems are using the Native POSIX Thread Library now, for which this function is irrelevant) you can use pthread_kill_other_threads_np() to send SIGKILL to all other threads, usually to correct a deficiency whereby other threads are not terminated when calling one of the exec() family of functions.

The signal mask for a thread can be accessed/modified with pthread_sigmask(), which uses a sigset_t that can be manipulated with the usual sigsetops.

Scheduling and CPU time/affinity

The clock_t of a specific thread (e.g. for a call to clock_gettime()) can be accessed with pthread_getcpuclockid().

A thread's scheduling policy and parameters (i.e. priority) can be accessed/modified using pthread_setschedparam() and pthread_getschedparam(). The priority alone can be set using pthread_setschedprio(). The CPU can be released with pthread_yield(), which is analogous to sched_yield() but for an individual thread.

Note: This is irrelevant on Linux, and is ignored. The concurrency (a hint to the system about how many lower-level entities (e.g. kernel threads) to assign) of a process can be accessed/modified with pthread_getconcurrency() and pthread_setconcurrency().

The CPU affinity of a thread can be accessed/modified after creation with the GNU-specific pthread_getaffinity_np() and pthread_setaffinity_np().

Thread-specific data and one-time-only operations

Once-only initialization can be achieved using pthread_once(). This requires a pthread_once_t which is initialized by assignment from the PTHREAD_ONCE_INIT macro.

Thread-local data is provided through a pthread_key_t, which is initialized/freed using pthread_key_create() and pthread_key_delete(). The value can then be accessed/modified using pthread_getspecific() and pthread_setspecific().

Locking mechanisms

Pthreads provides three types of locking mechanism - mutexes, read/write locks and spin locks.

Mutexes

These are the most common types of lock, as well as the most flexible. They are also the only locks that can be used with condition variables.

A mutex is initialized/freed with pthread_mutex_init() and pthread_mutex_destroy(). You can also initialize a statically allocated mutex using the PTHREAD_MUTEX_INITIALIZER macro or, as GNU extensions, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP or PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP.

Mutexes can optionally be initialized with attributes in the form of a pthread_mutexattr_t, initialized and freed using pthread_mutexattr_init() and pthread_mutexattr_destroy(). The pthread_mutexattr_t can have the following operations performed on it:

• The type of mutex used can be accessed/modified using pthread_mutexattr_gettype() and pthread_mutexattr_settype(). A mutex can be normal, error-checking (re-locking the mutex from the owning thread is an error) or recursive (relocking the mutex from the owning thread is fine).
• Whether a mutex can be used from multiple processes can be accessed/modified using pthread_mutexattr_getpshared() and pthread_mutexattr_setpshared().
• To prevent priority inversion, the behaviour of a thread's scheduling while a mutex is locked and/or blocking higher priority threads can be accessed/modified with pthread_mutexattr_getprotocol() and pthread_mutexattr_setprotocol(). The priority ceiling of a mutex can be accessed/modified with pthread_mutexattr_getprioceiling() and pthread_mutexattr_setprioceiling().

The priority ceiling of a thread can be accessed/modified after creation using pthread_mutex_getprioceiling() and pthread_mutex_setprioceiling(). Mutexes can be locked using any of pthread_mutex_lock(), pthread_mutex_timedlock() or pthread_mutex_trylock(). They can be unlocked with pthread_mutex_unlock().

Read/write locks

Read/write locks can provide performance benefits over mutexes since they allow any number of threads to access the protected resource with "read-only" behaviour, while granting exclusive access to threads that want to be able to modify the resource. They have some disadvantages over mutexes though, namely that they can't be configured to avoid priority inversion and they can't be used with condition variables.

A read/write lock is initialized/freed with pthread_rwlock_init() and pthread_rwlock_destroy(). You can initialize a statically allocated read/write lock with PTHREAD_RWLOCK_INITIALIZER or, as a GNU extension, PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP.

Read/write locks can optionally be initialized with attributes in the form of a pthread_rwlockattr_t, initialized and freed using pthread_rwlockattr_init() and pthread_rwlockattr_destroy().

Currently, the only attribute a read/write lock can be given is whether it can be used by multiple processes. This setting can be accessed/modified with pthread_rwlockattr_getpshared() and pthread_rwlockattr_setpshared().

A read lock can be obtained using one of pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock() or pthread_rwlock_tryrdlock(). The corresponding functions for obtaining the write lock are pthread_rwlock_timedwrlock(), pthread_rwlock_trywrlock() and pthread_rwlock_wrlock(). The lock can be unlocked from either type of lock with pthread_rwlock_unlock().

Spin locks

These are the simplest form of locks, and are generally only used when you know that other threads will only be holding the locks for a short amount of time (e.g. not whilst performing blocking I/O).

A spin lock is initialized/freed with pthread_spin_init() andpthread_spin_destroy(). There is no associated attributes structure (but they can be made available to other processes upon initialization).

The functions for locking/unlocking a spin lock are pthread_spin_lock(), pthread_spin_trylock() and pthread_spin_unlock().

Memory barriers

These allow threads to synchronize at a pre-defined point of execution.

They are initialized and freed using pthread_barrier_init() and pthread_barrier_destroy().

A memory barrier can optionally be initialized with attributes in the form of a pthread_barrierattr_t, initialized and freed using pthread_barrierattr_init() and pthread_barrierattr_destroy().

Currently, the only attribute a memory barrier can be given is whether it can be used by multiple processes. This property can be accessed/modified using pthread_barrierattr_getpshared() andpthread_barrierattr_setpshared().

Once created, threads can synchronize at a barrier using pthread_barrier_wait(). There is no such thing as a "trywait" or "timedwait" function.

Condition variables

Condition variables can be used to signal changes in an application's state to other threads. They must be used with an associated pthread_mutex_t.

Condition variables are initialized/freed using pthread_cond_init() and pthread_cond_destroy().

A condition variable can optionally be initialized with attributes in the form of a pthread_condattr_t, initialized and freed using pthread_condattr_destroy() and pthread_condattr_init(). You can initialize a statically allocated condition variable using PTHREAD_COND_INITIALIZER.

Whether the condition variable is able to be used by multiple processes can be accessed/modified using pthread_condattr_getpshared() and pthread_condattr_setpshared().

The clock used (identified by a clockid_t) for timed waits on a condition variable can be accessed/modified using pthread_condattr_getclock() and pthread_condattr_setclock() (though it cannot be set to a CPU clock).

Threads can wait for changes in conditions using pthread_cond_timedwait() and pthread_cond_wait().

Threads can signal changes in conditions using pthread_cond_broadcast() and pthread_cond_signal().

3 Films 1 Room

Recently I was trying to think of all the films I could that are set (almost) entirely in a single room, and a thought struck me; the good ones are some of the best films I know. I'm not sure why this is. Maybe they're a case of constraints breeding creativity? Maybe I just love dialogue-driven films? Maybe I just forget the bad ones? (Although Exam would be a counter-example to that - I want my money back, and I didn't even pay anything to see it*). Here are my three favourite almost-but-not-quite-cult examples.

There are no spoilers.

Tape

Set in a motel room, two old high-school friends discuss old times, eventually leading to old accusations resurfacing and some very heated moments in such a small space. Ethan Hawke, Robert Sean Leonard and Uma Thurman all give excellent performances.

The Man from Earth

Professor John Oldman gets accosted by friends before he can leave his whole life behind, seemingly for no reason and not giving anyone any clues as to where he's headed to next. Pushed for the reasons for such a hasty escape, he confesses to being 14,000 years old, periodically moving when people notice he doesn't age. His academic colleagues try to pick holes in his story, but he makes them doubt themselves with an answer for every question.

This film is famous in cult circles for being filmed on a budget of $200,000 (not much for a film these days) and being publicised mostly through word-of-mouth on the internet (or should that be "word-of-keys"?) - the producer even commenting on how positive file sharing has been in getting word of the film out.

Conspiracy

A gripping portrayal of the Wannsee Conference, depicting the German high command discussing the "Final Solution" behind closed doors. I'm not much of a history buff, but this film really did engage me. Although this film isn't strictly all in one room all the action (by which I mean dialogue; it feels like action) and a large part of the film does, and the rest is not far away.

"Was it a play?"

For some reason, when I mention to someone that a film is set mostly or entirely in a single room, they often ask if it's an incarnation of a play (as if a screenwriter could ever bring such a restriction upon themselves). So far as I know, of the offerings above only Tape started out in life as a play, although The Man from Earth was subsequently made into one.


* It was on TV - lose one hundred million points if you briefly hated me in your head for downloading films. Win one hundred million points back if you still hate me for preempting you; I like that.

The Cumbrian Run, or: How Not to Finish Training for a Distance Run

Well, the Cumbrian Run is over for another year, yet again leaving me with what feels like the legs of an 80-year-old man. The previous two years have been a bit of a let-down, with me not training as much as I could (especially last year) and being disappointed with my result. Last year's was 2:25, the previous was 2:15. So last year, I vowed to train all year and really boost my time. Which I did. Well... ish.

My training started off well, but throughout the year I'd had a couple of breaks of a few weeks or so due to commitments and general laziness. And the last couple of weeks I've been preparing for an exam, as well as just experiencing general apathy for the whole running thing (these things come and go, I guess). This may not be the best time, but priorities are priorities.

Anyway, about a month or so ago I would have estimated I could get a 1:50 time fairly confidently, so that's what I was aiming for and the pace I set off at. You couldn't ask for much better weather - still, sunny and fairly cool. Setting off, the first four miles felt pretty good aside from a pain at the back of my ankle - I don't normally get pain here, so that wasn't a good sign. Then Disaster Strikes! in the form of my watch stopping. It's a Garmin Forerunner 305. I've never had any problems with it in the past, and I'm sure I didn't knock it/into anyone, so this is puzzled me somewhat.

Anyway, at mile four I reset it and got on with things. The next four miles were pretty painful but I managed to keep up the pace, then the next three I dropped it a bit. I was happy with my last mile though - it was faster paced than my average for the race, and the crowd really helped me finish.

In the end, I ended up with a 1:52:13 chip time, which I was fairly pleased with - although I was hoping for under 1:50 going in, I wasn't sure how two weeks of sitting on my arse would affect things (and I still don't - would I have knocked two minutes off my time with extra training? Who knows...) my aim from last year was to get under 2 hours, so I can be happy with that. And I knocked over 32 minutes off my time - if I continue at this rate, I'm on for a pretty good time next year...

Chilli Confusion: Win for Evolution

I love chilli peppers. They go great in various foods as well as just whole in a nice glass of wine. I also think they (as well as tomatoes) have a neat method of seed propagation: they get eaten by animals and let their seeds be "distributed" when their digestive systems are done with them. This apparently works well for them, since they get (i) a nice new home in foreign climes and (ii) a toasty warm bed of fertilizer to start life off with.

However, at same time this has always confused me - while I love them cut up and mixed into my food, if I were your average grazing mammal and decided to try biting into a chunk of chilli for the first time, the intense burning sensation in my mouth would soon put an end to such a behaviour. But if they get propagated in the same way as tomatoes, why would they want to ward off their middle-men?

Obviously, there's a perfectly reasonable explanation for this, but neither my teacher at school nor the then-infantile dial-up internet of the time could provide said explanation. Revisiting the problem recently gave me the answers I craved. The heat in chillies arises from evolutionary forces that depend on two major factors that make the answer kind of obvious when you know them, and are a veritable marvel of nature (at least, I think so...).

First, there's the fact that while we perceive chillies as having a hot, burning sensation, birds don't. In humans and other mammals, the capsaicin in chillies activates the same pain receptors as direct application of heat does*, but birds don't have these and so are basically unaffected by this.

Secondly, the seeds in chillies are vulnerable to mammalian digestive tracts - they are harmed when they pass through them, but not when they pass through avian digestive tracts. Thus, a chilli's heat is how it selects its preferred "thing to be eaten by".

So that's my curiosity satisfied, and since it was such a nice evolutionary arrangement I thought I'd share.


* Though it doesn't feel quite the same as actual heat applied to the inside of your mouth (at least to me) because you don't get other consequences of heat (e.g. tissue cell damage and the resultant release of various substances with further consequences). But it really is the same pain receptors that get stimulated (these ones, if you're so inclined), just in a different way.

Invisibility in Fiction

I'd like to comment on a subject I feel very strongly about at a quite personal level. I feel this issue is important, despite being overlooked by many serious authors of various backgrounds and heights. Quite frankly, it gets right on my tits.

It is this:

An invisible person would be blind.

This is, of course, ignoring any invisibility obtained through magic or similar, since then an author can also get around this problem with hand-waving and magic. I'm talking more about the sort of thing described in H. G. Wells' The Invisible Man*, or the modern film Hollow Man, where people are described as simply having all their matter turn completely transparent somehow. Fringe cases (such as the girl in The Incredibles) could be argued either way, I guess.

Anyway, as you may well know, the big problem is that in order to see, your retina has to absorb light (hence why it's black). But if you're invisible in the way described (i.e. everything that constitutes you/your body is completely transparent), light would pass through your retina, the photoreceptive cells that turn light into neural signals never would get stimulated, and you'd be as blind a completely blind person.

There are a few ways you could try and get around this. In the The Invisible Man, H. G. Wells attempts to do so by describing the recently-made-invisible protagonist's retinae** as being translucent in chapter 20: an attenuated pigment still remained behind the retina of my eyes, fainter than mist.

Of course, this state of affairs would be no better than being blind. Without an optically correct cornea, lens and associated fluids that make your eyes so juicy and delicious, light would not get focused on your retina - the best you could hope for is a blur. And even if these weren't completely transparent and had their normal optical properties, without an opaque sclera (the white that surrounds the rest of your eye) light would be arriving at your retina from all other directions, meaning the world would be a big white blur. In order to see, you'd need these bare essentials to be unaffected by any invisibility remedy, but that would leave you with two very distinct and conspicuous white spheres bobbing around at everyone else's eye-level (unless you're very short/tall or you want to go around crouching).

As an aside, if you could really do this you may actually see better than you do ordinarily. The photoreceptors in your retina are orientated with their photoreceptive pigment at the back of your eye, meaning the cell bodies as well as various retinal processing cells that aggregate/mediate their responses are all in front of the receptors themselves, in the path of the light. I don't know how much it would actually improve your sight, but it wouldn't be by a vast amount - the best values of visual acuity that have been measured are not much better than the theoretical limit, given the distance between adjacent photoreceptors in the retina.

In conclusion, next time I'm watching a film with an invisible person in it, I'll just pretend they suddenly developed extraordinarily good echolocation.


* An attempt at reconciling this problem is made in the book - see later.
** This is a weird one - saying "retinae" instead of "retinas" sounds weird to me, but writing "retinas" instead of "retinae" looks equally weird. And anyway, both are acceptable and I like writing footnotes.

S205 - Advice for Starters

As an addendum to a previous post with my thoughts on S205 in general, here's some advice I posted to the S205 group on The Facebook when someone asked. By the way, if you're doing an OU course the Facebook groups are great - there's a much friendlier atmosphere than on the course forums.

• Make sure you understand Book 2 and Book 3 Part 2 really well, as they come up throughout the course.
• Book 5 Part 2 introduces you to reaction mechanisms and other concepts which are also fundamental to organic chemistry in later parts of the course (Books 5(3), 7 and 10), so it (and the exercises) should also be read thoroughly.
• The TMA questions tell you which book they're about - read the questions before reading the books. You can then pick up the answer as you're going through, rather than forgetting all about the topic and perhaps missing something important.
• Conversely, don't think you've got a TMA question complete until you've read the entire book that it's on. Sometimes, general rules that look right are altered by niche conditions/whatever, which is what the TMA is really asking about.
• Book 8 Part 1 and Book 9 (past chapter 4) can be largely avoided, if you like. I read (but made no notes) on Book 8, and skipped 9 as much as possible. This seemed like a popular option as it's very, very dry! Our TMA question on Book 9 was about a specific chapter, so you can just focus on that.

S205 - The Molecular World

So, I'm part-way to a natural sciences degree with the Open University. My first course was S205 The Molecular World (well, really it was DSE212, but that was a few years ago and not with a view to my current degree). I like reading what other people thought of courses and the nitty-gritty of them from a student's perspective, so I thought I'd present my views on said course here. So that you know where this view point is coming from, my first degree was in maths and the last chemistry I did was at A-level around 10 years ago.

If you're interested, I've also written a brief post on some advice if you're starting this course.

Course Books and Content

Book 1 of the course is short and sweet (just over 20 pages) and basically acts as an introduction to/taster for the course the case studies (which I'll come back to later).

Book 2, Introducing The Molecular World (~70 pages) is an overview of some of the "bread and butter" chemical knowledge that you'd need throughout any chemistry course - the basics of atoms, chemical bonding and chemical/electronic structure, the periodic table and patterns in it, functional groups, molecular shape and reactivity. These are all set out at a fairly basic level, since each topic is taken into much greater detail in later books, but you need at least a grounding in them all to be able to really understand later material. How you get on with this depends on your background; if you've got a good chemical background (e.g. a recent A-level) you'd probably be able to skim through most of this effectively, but it would be understandable (with a little effort) for someone with little or no background in chemistry. Like I said, my last chemistry course was 10 years ago, so things were a bit hazy for me but I felt like this was a good, solid and fairly interesting start to the course.

Book 3, The Third Dimension comes in two parts - Crystals (~95 pages) and Molecular Shape (~50 pages). I found the part on crystals to be fairly dry, which was a bit off-putting so early in the course. A fair chunk of it was describing the characteristics of different crystal structures, which went in one ear and out the other; it struck me more as the sort of thing I'd have to memorize before the exam. That part starts with a general discussion of close-packed arrays of spheres and how this reflects the internal structure of metals before moving on to the structure of ionic solids, ionic radii in crystals, molecular crystals and defects in crystal structures.

I found the second part of book three much more interesting. It covers molecular shape including isomerism, chirality (molecules with mirror images that aren't identical) including molecules with many chiral centres and chiral centres in ring structures.

Book 4, Metals And Chemical Change (~190 pages), seems fairly thick, but a lot of it is a fairly gradual introduction to the core principles you actually need to remember - you can miss a good few chapters out of your revision, for example. It covers thermodynamics, why some reactions happen while others don't (and how to predict which ones will happen), the Born-Haber cycle and the extraction of metals from their ores. It finishes by applying these concepts specifically to group I and II metals.

Book 5, Chemical Kinetics and Mechanism is broken down into (obviously) Chemical Kinetics (~95 pages), The Mechanism of Substitution (~45 pages) and Elimination: Pathways and Products (~25 pages). Chemical kinetics links in nicely with both the previous book and the later parts of the book - instead of looking at whether a reaction will happen, it looks at how fast it will happen, what factors affect the speed of a reaction and how this information can be predicted from/used to suggest the mechanism of the reaction. This is probably the most maths-heavy part of the course, and some people found the maths here to be a little bit of a challenge - if you've got a good grasp of algebra and logarithms it's a breeze, otherwise make sure you understand the maths help that's provided and you'll be fine.

The second part of book 5 discusses substitution - one of the three major classes of organic reaction mechanism (the others being elimination and addition). It starts off with a general discussion of reaction mechanisms and how to draw/describe them using chemical notation before applying these principles directly to the two types of substitution mechanism, as well as what factors affect which mechanism will be preferred by a reaction.

The third part of book 5 is similar to the second part, only discussing a different type of mechanism and without the need for the general introduction to reaction mechanisms. This was nice; it was good to see material that was brief because you'd already learned the underlying principles.

Book 6, Molecular Modelling and Bonding (~100 pages) goes into details about the techniques used to predict what shapes molecules will adopt, moving on to quantum chemistry, symmetry, atomic and molecular orbitals (i.e. the shape of electron clouds) and how these affect molecular reactivity, and the bonding in metals and semiconductors. I found the section on how semiconductors work and semiconductor doping particularly interesting.

Book 7, Alkenes and Aromatics is broken down into Addition - Pathways and Products (~20 pages), Aromatic Compounds (~35 pages) and A First Look at Synthesis (~40 pages). The first part draws together the principles of reaction mechanisms from book 5 as well as the material on molecular orbitals from book 6 to look at the mechanism of the last of the major classes of organic reaction. Hence the brevity again - you should be familiar with the basic principles from the last two books, this book just squishes together in a fairly neat way to form a coherent whole.

The second part of book 7 discusses benzene, the basis of all aromatic compounds, including its orbital structure. It also looks at substitution reactions applied to benzene and how substituents affect these reactions. The final part is a precursor to book 10 - it looks at how synthetic routes (i.e. ways of synthesizing drugs and other chemicals) are planned, the issues involved, how to construct simple synthetic routes and how changes in existing ones will affect the outcome.

Book 8, Separation, Purification and Identification is broken down into Chemistry: A Practical Subject (~65 pages) and Spectroscopy. The first part covers methods for the separation and purification steps of this book's title. I found this section fairly dry and we were told before-hand that this section wouldn't be examined, so I didn't study it very in-depth.

The second part of book 8 is entirely taught via a computer program - revision notes were available on the course website though. It goes fairly in-depth into the theory behind both infrared and NMR spectroscopy before covering how to interpret both types of spectra for a wide range of organic compounds. The program was interactive, allowing you to try your hand at interpreting IR/NMR spectra, eventually using both together to determine the structure of some quite complex molecules. I enjoyed this part of the course as it was mainly about problem solving - applying a little bit of knowledge in sometimes fairly complicated ways.

Book 9, Elements of the p Block is a fairly beefy size (~205 pages) and covers acids and bases as well as hydrogen chemistry, but the bulk of the book is dedicated to patterns and trends in the p block (groups III-VIII, the largest block of the periodic table). I can't really comment too much on this book except that this was by far the least enjoyable part of the course for me - it reads a lot like a huge list of facts to remember, and felt like wading through xenon-infused treacle. In short: Not my cup of tea. I quickly decided I wanted little to do with this material, but this wasn't too much of a problem as the structure of exam meant that certain parts of the course can be skimmed over, if not totally skipped, (so long as you're prepared to do more work on certain other parts of the course) and book 9 was one of them. The upshot was that I read just enough to do the assignment question (though not very well...) on this book before ignoring it.

Book 10, Mechanism and Synthesis is the final and largest of the course books, and consists of Carbonyl Compounds (~40 pages), Synthetic Applications of Organometallic Compounds (~35 pages), Radical Reactions in Organic Synthesis (~40 pages), Strategy and Methodology in Organic Synthesis (~75 pages) and finally Synthesis and Biosynthesis: Terpenes and Steroids (~40 pages).

The first part discusses the chemistry of the carbonyl group (carbon double-bonded to oxygen), which has a number of uses in reaction synthesis. The second part describes how various organic compounds that include a metallic element can be used in synthesis, another important class of reactions. The third part discusses radical reactions, which involve a different type of bond separation than normally found, including chain reactions. Part four picks up where the last part of book 7 left off, covering approaches for planning more complex synthetic routes. I found this part very enjoyable as it brings together previous parts of the course to solve the sorts of problems found in synthesis. It soon became apparent that chemical synthesis at this level really is more of an art form than a science. The final part of the course covers the synthesis of some naturally occurring compounds.

Course Software

I found the software easy to use and helpful, though there was a fair bit to install and some of it was redundant - e.g. there were two chemical drawing programs to install, one an updated version of the other (though I didn't realize this until I'd installed them). The software for book 8 (spectroscopy) was easy to use, and I found the puzzle-solving in it quite fun.

However, I was running the course software under Windows XP - some people using Windows Vista or Windows 7 had issues installing and using the software, but so far as I know they seemed to get resolved in the end. The conference software for remote tutorials didn't work very well under Linux (the audio was very broken) but worked fine when I booted into XP.

Assignments and The Exam

The assignments were fairly challenging at times, but certainly doable if you cover the material well. The questions were nice and specific (some students have complained of vague, wishy-washy questions in other courses) and there were no essay/experiment write-up type questions (though I got the impression there were in previous presentations). In addition to 6 tutor-marked assignments there were also 2 interactive computer-marked assignments (i.e. you answer numerical/multiple choice questions on a web page). I found the computer assignments useful for jogging my memory; whereas the tutor-marked assignments were all about the recent topics we'd covered, the computerized ones covered the whole course up until that point, and so forced you to revisit earlier material. Some found this a pain, but I was glad for the chance to revise and consolidate everything so far.

I found the exam fairly easy to prepare for - there was an exam guide that laid out what sections would be covered. As I said before, this meant you could selectively ignore certain parts of the course - not an awful lot, and you needed a decent grasp on most of it. A certain amount of "question spotting" was possible, but not very much.

The exam itself consisted of four sections. The first constituted 40% of the marks and had 12 questions, though you only had to answer 8, which is a fairly generous amount of choice if you ask me. These questions could be taken from any part of the course, but weren't too in-depth. The remaining three sections each had three longer questions, but you only had to answer one from each section (i.e. three questions in total). These were each worth 20% of the total marks for the exam and so required much more detail but, as mentioned before, the organization allowed you to focus revision on a few subjects, within certain limitations.

I found the assignments and exam manageable - I ended up with a distinction overall, so I was pretty happy with that.

Overall

The course started out moderately paced - the workload picked up towards the end (roughly from book 6 onwards) but I never found it overbearing. I liked how the sections linked together and built upon each other in a nice, logical way (especially the organic chemistry).

There were case studies at the end of each book from book 3 onwards. They build on the material in the book but with a more specific "real life" application in mind (e.g. the chemistry of liquid crystals or high-temperature semiconductors). They're not required or assessed at any point - they're purely there for interest. While what I did read was interesting, I didn't have time to read much of them.

Overall, I found this course really interesting, even if there were a couple of sections that were a bit dull, and I feel I gained a lot from it.

Vague Essays (in SD329)

I'm doing a level 3 (3rd year) science course with the Open University (SD329, if you're interested). As part of the assignments, this course includes some essays; not a big deal, I've done a course with 2-3 thousand word essays in it before. But this is the first one where the essay questions were rather vague.

There was a lot of talk on the course website/The Facebooks about this. Humanities students might be used to these sorts of essay questions, but it seemed to really phase some students when they did their assignments. I was a little put off at first, but then when talking to my tutor about what they were looking for, it became quite clear that, at least in OU science courses:

If you're given a vague essay question, it's for a good reason.

This is generally because either:

• You've only covered so much material on that topic, and writing an essay about it all in the word count would be easy (even if you include some extra research) or, more likely,
• They're deliberately giving you scope to waffle on about whatever you want, so long as you keep to the general topic.

Once I realised this, it became more easy to think of them as "open-ended" essays as opposed to vague ones; the people who set the assignment don't have some secret, hidden question they "really" want answered, they just want you to talk about anything on the topic.

This whole thing may seem obvious to you; but it's the sort of implied knowledge nobody has told me (and at least a few others on my course) about. Science students generally like to know exactly what's required when doing an assignment, so being given free reign over a topic can be a little uncomfortable/unnatural at first - but realizing that it's expected makes writing these sorts of essays much easier.

Running a program and interacting with it.

Here's an example of a function, ccl_popen3(), that opens a program with the standard streams that you want to write to/read from open. It's from a while ago, I'll brush it up later (in theory).

Either way, ccl_popen3() is the money function, and main() demonstrates usage. Compiles on my machine with gcc popen3.c -o popen3 -std=gnu99 -Wall -Wextra -Werror.

#include <stdlib.h>
#include <unistd.h>

#define READ_END  0
#define WRITE_END 1
#define NENDS     2

#define OPEN_STDIN  (1 << STDIN_FILENO)
#define OPEN_STDOUT (1 << STDOUT_FILENO)
#define OPEN_STDERR (1 << STDERR_FILENO)
#define OPEN_ALL    (OPEN_STDIN | OPEN_STDOUT | OPEN_STDERR)
#define MAX_STREAMS 3



__attribute__((noreturn))
static void popen3_child(const char *exe,
                         char *const argv[],
                         int shell,
                         int streams,
                         int pipes[MAX_STREAMS][NENDS])
{
    for (int i = 0 ; i < MAX_STREAMS ; i++)
        if (streams & (1 << i)) {
            close(pipes[i][i == STDIN_FILENO ?
                           WRITE_END : READ_END]);
            if (dup2(pipes[i][i == STDIN_FILENO
                              ? READ_END : WRITE_END],
                     i) == -1)
                exit(127);
        }

    if (shell)
        execvp(exe, argv);
    else
        execv(exe, argv);

    /* Any return from execv()/execvp() is an error. */
    exit(127);
}

static void popen3_parent(int streams,
                          int fds[],
                          int pipes[][NENDS])
{
    for (int i = 0 ; i < MAX_STREAMS ; i++)
        if (streams & (1 << i)) {
            close(pipes[i][i == STDIN_FILENO ?
                           READ_END : WRITE_END]);
            fds[i] = pipes[i][i == STDIN_FILENO ?
                              WRITE_END : READ_END];
        }
}



/*
 * TODO: (i) different functions for child and parent, (ii)
 * close original pipe fd's.
 */
pid_t ccl_popen3(const char *exe,
                 char *const argv[],
                 int shell,
                 int streams,
                 int fds[])
{
    int pipes[MAX_STREAMS][NENDS] = {{-1, -1},
                                     {-1, -1},
                                     {-1, -1}};

    for (int i = 0 ; i < MAX_STREAMS ; i++)
        if ((streams & (1 << i)) && (pipe(pipes[i]) == -1))
            goto err;

    pid_t pid = fork();
    switch (pid) {
    case -1:  /* error */
        goto err;
    case 0:   /* child */
        popen3_child(exe, argv, shell, streams, pipes);
        break;
    default:  /* parent */
        popen3_parent(streams, fds, pipes);
        return pid;
    }

 err:
    for (int p = 0 ; p < MAX_STREAMS ; p++)
        for (int e = 0 ; e < NENDS ; e++)
            if (pipes[p][e] != -1)
                close(pipes[p][e]);

    return -1;
}



#include <poll.h>
#include <stdio.h>

void ccl_poll_input(int fds[3])
{
    struct pollfd pollfds[2] = {
        { .fd = fds[STDOUT_FILENO], .events = POLLIN },
        { .fd = fds[STDERR_FILENO], .events = POLLIN }
    };

    int running = 1;
    while (running) {
        int res = poll(pollfds, 2, -1);

        if (res == -1) {
            perror("poll()");
            exit(EXIT_FAILURE);
        }

        struct pollfd *pfd = pollfds;
        for (int i = 0 ; i < 2 ; i++, pfd++) {
            if (pfd->revents & (POLLERR | POLLNVAL)) {
                fprintf(stderr, "poll() error\n");
                exit(EXIT_FAILURE);
            }

            if (pfd->revents & (POLLIN | POLLHUP)) {
                char buf[1024];
                ssize_t nread = read(pfd->fd,
                                     buf, sizeof(buf) - 1);

                if (nread == -1) {
                    perror("read()");
                    exit(EXIT_FAILURE);
                }

                if (nread == 0) {
                    /* EOF */
                    running = 0;
                    break;
                }

                buf[nread] = '\0';
                printf(" Read from %d: \"%s\"\n",
                       pfd->fd, buf);
            }
        }
    }
}



#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <poll.h>

int main(void)
{
    int grep_fds[3];

    const char *exe = "/bin/grep";
    char *const argv[] =
      {"grep", "-h", "XX", "jkfdsl", "-", NULL};
    
    pid_t grep_pid =
      ccl_popen3(exe, argv, 0, OPEN_ALL, grep_fds);

    if (grep_pid == -1) {
        perror("ccl_popen3()");
        exit(EXIT_FAILURE);
    }

    /* Write some input to grep's standard input, and close
     * it. */
    const char *input = "abcd\ngg9XXp\nDqdXXpird\n";
    if (write(grep_fds[STDIN_FILENO], input, strlen(input))
        != (ssize_t)strlen(input)) {
        perror("write()");
        exit(EXIT_FAILURE);
    }
    close(grep_fds[STDIN_FILENO]);

    printf("out: %d, err: %d\n", grep_fds[STDOUT_FILENO],
           grep_fds[STDERR_FILENO]);

    struct pollfd pollfds[2] = {
        { .fd = grep_fds[STDOUT_FILENO], .events = POLLIN },
        { .fd = grep_fds[STDERR_FILENO], .events = POLLIN }
    };

    int running = 1;
    while (running) {
        int res = poll(pollfds, 2, -1);

        if (res == -1) {
            perror("poll()");
            exit(EXIT_FAILURE);
        }

        struct pollfd *pfd = pollfds;
        for (int i = 0 ; i < 2 ; i++, pfd++) {
            if (pfd->revents & (POLLERR | POLLNVAL)) {
                fprintf(stderr, "poll() error\n");
                exit(EXIT_FAILURE);
            }

            if (pfd->revents & (POLLIN | POLLHUP)) {
                char buf[1024];
                ssize_t nread = read(pfd->fd,
                                     buf, sizeof(buf) - 1);

                if (nread == -1) {
                    perror("read()");
                    exit(EXIT_FAILURE);
                }

                if (nread == 0) {
                    /* EOF */
                    running = 0;
                    break;
                }

                buf[nread] = '\0';
                printf(" Read from %d: \"%s\"\n",
                       pfd->fd, buf);
            }
        }
    }

    int grep_status;
    if (waitpid(grep_pid, &grep_status, 0) == -1) {
        perror("waitpid()");
        exit(EXIT_FAILURE);
    }

    if (WIFEXITED(grep_status))
        printf("grep exited with status %d\n",
               WEXITSTATUS(grep_status));
    else
        // TODO: This better.
        printf("grep terminated abnormally\n");
    return EXIT_SUCCESS;
}

C on Linux Kickstart

Overview

So, there are plenty of resources for learning how to program in C/C++ (see the end of this post) but here's a quick guide on how to get off to a good start with the practical matters. It's the sort of stuff I wish someone had pointed out to me when I started, since it would have made my life a lot easier.

While graphical IDE's may make your life easier for large projects, a knowledge of how the core tools used in making programs fit together is essential if you're going to go anywhere with your programming; where more complex tools let you down, you can pick yourself up if you know what they're doing behind the scenes. This is why this guide will start you off using the compiler on the command line.

The command line

If you're not already used to using the command line, have a look at this chapter of Introduction to Linux: A Hands On Guide. You'll need to get comfortable with moving around the file system, creating and listing the contents of directories, etc.

What to use & install

The two absolute essentials you'll need are (i) a text editor and (ii) a compiler. You might already be a fan of the text editors vi or emacs, both popular with programmers, but they can have a steep learning curve. If you've got a graphical Linux distribution it will have a default text editor that will doubtless have syntax highlighting (this makes certain parts of your source code stand out). The defaults for Gnome, Kde and Xfce are gedit, kate and mousepad respectively. So from the command-line, you can open e.g. the file program.c from a Gnome desktop by typing the following at a terminal:

    gedit program.c

As for a complier, by far the most popular option is GCC. On Debian/Ubuntu, you can install this, as well as all the development libraries you'll need, by installing the build-essential package (as root):

    apt-get install build-essential

On Fedora/Red Hat, the same effect can be achieved by:

    yum groupinstall "Development Tools" "Development Libraries"

If you have another distribution and you're not sure what to install, ask around; if you can compile the main.c program in the next section, you have what you need.

How to compile programs

To give us something to work with, open your text editor of choice, write the following into it (copy & paste if you like/you get errors) and save it as main.c:

#include <stdio.h>

int main()
{
    printf("hello world\n");
}

We won't go into what the statements mean (I'll leave that to the tutorials at the end of this post) but this gives us something practical to work with.
Now, you can't run this file directly, you first have to compile it into a file that you can. The simplest way to do this is:

    gcc main.c

This will produce a file called a.out. You can run this in the usual way (from where you are just after compiling, type ./a.out). If you like, you can specify the output file to be something different by using -o filename (e.g. gcc main.c -o main).

However, you will make your programming life easier if you never compile your programs like this; it will lead you down a bad path. When you compile programs like this, you will let GCC ignore many potentially dangerous practices. Luckily, GCC has a way to alert you to these in the form of its warning options - they control what situations GCC will warn you about, and what situations it will silently ignore. The defaults are pretty lax, and while they may be useful in compiling legacy code you know to work and just want to compile, when learning and/or writing new code, you want your compiler to be as strict as possible. There are an endless variety of options you can fine-tune this strictness to your heart's content if you like, but for now there are three that will serve you very well: -Wall, -Wextra and -Werror. The first two of these enable a group of common warnings, and the last turns all warnings (that would usually just cause the compiler to emit a message about the offending construct) into errors that cause the compiler to flat-out refuse to finish compiling your program until you've sorted the error out.

These warnings are there for a reason; use them. They will prevent you from making mistakes that will lead to bugs that will just needlessly waste your time. A quite common forum post from new programmers reads essentially "here's a program that doesn't work the way I expect - help!". At least 50% of the time, I can copy + paste the program and compile with -Wall -Wextra and the result will tell me what they've done wrong, without even having to look at their program. Why spend time searching for errors when you can let your compiler do it for you?

In short, always compile your programs with at least -Wall -Werror - try it now with our main.c above:

    gcc main.c -o main -Wall -Werror

You'll notice I've not included -Wextra in the above command-line. -Wextra can be a bit harsh, especially on new programmers; use it to double-check a program that's not behaving as you expect, or for any code you hope to give to others (including posting it on a forum) for a thorough sanity-check first.

Dealing with error messages

There is one golden rule when dealing with error messages. At first you (like me) will probably ignore it, only to learn through bitter experience that it applies no matter how experienced you are. Luckily, it's very simple:

• Always deal with the very first error message emitted by the compiler.

The reason for this is quite simple: once the compiler sees something wrong, it's very likely that later things will make even less sense to it than they ordinarily would. So find the first error the compiler spots, fix it, then try recompiling. Often you will fix several error messages by fixing one actual error.

The error messages emitted by GCC are always in the format file:line[:position]: ERROR MESSAGE. If you've tried compiling the above main.c with -Wall you may have already seen the following:

    main.c:6:1: warning: control reaches end of non-void function

This lets us know that the error occurred in main.c on line 6 (and was estimated to be at character 1, but that's rarely useful). Exactly what this means you'll learn in time, but in this case we can fix this by turning main.c into:

#include <stdio.h>

int main()
{
    printf("hello world\n");
    return 0;
}

Try recompiling and you'll see no error message.

When you see an error message you don't understand, don't ignore it or start turning warning options off until it goes away. A quick copy-and-paste it into Google (leaving out any specifics like file names, function names and line numbers) will usually tell you exactly what's gone wrong:

    main.c:6:1: warning: control reaches end of non-void function

Where to go from here

There are several good introductions to programming in C on the web, my favourite being this one.

When you get stuck, forums can be invaluable - there is a Linux-specific forum with an active programming section here, and active forums for C and C++ programming here and here, respectively. You'll get good, fast responses if you include (i) code that demonstrates the problem you're having, (ii) what you think the code should do and (iii) what's going wrong.

Seeding Randomness

Note: This post is also a demonstration of a simple use of Pthread memory barriers.

Recently I read a discussion on choosing a suitable seed for srand() - ideally you want something random to seed srand() with, and one of the obvious suggestions was to use the current time. This lead me to wonder just how "good" a source of randomness the time is, and how likely two processes/threads are to find the time to be the same in practice.

The most coarse source of time is time(), which has a resolution of one second. Obviously, any program executed more often than every second is going to see the time to be the same as some other program.

Two much better functions in this respect are gettimeofday() and the newer clock_gettime(); they have a best resolution of one millisecond and one nanosecond, respectively (whether they actually have this resolution depends on your machine). But how likely are they to return the same time?

This being the sort of thing that keeps me up late into the night, I set up a program that attempts to spot two calls to one of these functions returning an identical time. My first attempt at just calling either one repeatedly and seeing whether the times were the same showed gettimeofday() frequently came out the same if called consecutively, whereas I couldn't get clock_gettime() to produce the same result twice. (Obviously since this is a practical (i.e. fudged) test, this result depends on my hardware, OS and possibly how my kernel is configured.) Anyway, undeterred I came up with a scheme using threads.

See the listing at the end of the program (with SYNC undefined) to see the attempt at just using raw threads. On my machine (stock Ubuntu 12.04 on a Core i5) with NUM_THREADS set to 300 (which was about as high as I could get it before getting memory allocation errors in pthread_create()) this program had to run 449 times (on average) to generate one run where only a single match for the time was found.

But we can do better than this. Creating a thread takes time - time during which the OS's unpredictable scheduling reigns supreme and with an iron fist, leading our threads to unpredictably diverge. We can force them all to synchronize at a point much closer to the call to get the time by using a Pthread memory barrier. We initialize the barrier with a count of NUM_THREADS, meaning any thread waiting at the barrier will wait until NUM_THREADS threads (i.e. all of our threads) are also waiting at the barrier before it is allowed to continue execution.* From here, there's a lot less logical "distance" to the clock_gettime() call, so we should be able to generate the same time more easily. The barriers in the listing at the end are enabled by passing the -DSYNC flag to gcc when compiling. Note that we get the time as soon as possible after getting past the barrier, and then check whether our barrier wait was successful, to keep the distance between getting past the barrier and getting the time as low as possible.

Using memory barriers, the number of runs we needed to make to get one match was reduced from 449 to 89. Using optimization (-O3) reduced this a little further to 62 times. So, my best attempt results in the same time being returned once every (at best) 62 * 300 = 18600 threads.

So, the conclusion? If I'm ever after high-quality random numbers for security purposes, I'll turn to /dev/random and/or /dev/urandom, but for any other application clock_gettime() is much simpler and should be more than enough for me.

/*
 * same.c
 *
 * See if we can get clock_gettime() to generate two times
 * that are the the same. Can be compiled with -DSYNC to use
 * a memory barrier in the thread to try and force the same
 * time to be retrieved.
 *
 * Compile with (where # is the number of threads you want):
 *
 *   $ gcc same.c -DNUM_THREADS=# [-DSYNC] -pthread -lrt
 *
 * Copyright (C) 2012 John Graham. This source code is
 * released into the public domain; you may use it as you
 * wish.
 */

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>

/* Array into which threads place their times. */
struct timespec times[NUM_THREADS];

#ifdef SYNC
/* Memory barrier at which threads sync (if applicable)
 * immediately before getting the time. */
pthread_barrier_t barrier;
#endif

void *thread(void *arg)
{
  /* Our argument is the index into 'times'. */
  intptr_t index = *(intptr_t *) arg;

#ifdef SYNC
  /* Wait at the barrier. This will block until all
   * threads are at the same point in their execution. */
  int pret = pthread_barrier_wait(&barrier);
#endif

  /* Get the time ASAP, *then* check the return value from
   * pthread_barrier_wait(). */
  if (clock_gettime(CLOCK_MONOTONIC, &times[index]) != 0) {
    perror("getting time");
    exit(EXIT_FAILURE);
  }
#ifdef SYNC
  if (pret != 0 && pret != PTHREAD_BARRIER_SERIAL_THREAD) {
    fprintf(stderr,
            "Waiting at barrier: %s\n", strerror(pret));
    exit(EXIT_FAILURE);
  }
#endif

  return NULL;
}

/* See if *any* of the entries in 'times' are identical. */
int compare_times(void)
{
  int nsame = 0;
  int i, j;
  for (i = 0; i < NUM_THREADS; i++)
    for (j = i + 1; j < NUM_THREADS; j++)
      if (times[i].tv_sec == times[j].tv_sec &&
          times[i].tv_nsec == times[j].tv_nsec)
        nsame++;
  return nsame;
}

int main()
{
  int i;   /* Generic index. */
  intptr_t nums[NUM_THREADS]; /* Indices to pass to
     * threads. */
  pthread_t threads[NUM_THREADS];

#ifdef SYNC
  if (pthread_barrier_init(&barrier,
                           NULL, NUM_THREADS) != 0) {
    perror("pthread_barrier_init()");
    exit(EXIT_FAILURE);
  }
#endif

  /* Start all our threads, initializing indices as we go
   * along. */
  for (i = 0; i < NUM_THREADS; i++) {
    nums[i] = i;
    if (pthread_create(&threads[i],
                       NULL, thread, &nums[i]) != 0) {
      perror("pthread_create()");
      exit(EXIT_FAILURE);
    }
  }

  /* Wait until all threads have finished. */
  for (i = 0; i < NUM_THREADS; i++) {
    if (pthread_join(threads[i], NULL) != 0) {
      perror("pthread_join()");
      exit(EXIT_FAILURE);
    }
  }

  int times = compare_times();
  printf("%d matches\n", times);
  return times;
}

* If you want a demonstration that the memory barrier is working, initialize it with a count of NUM_THREADS+1. Since this many threads will never wait on the barrier, every thread will sit and wait there indefinitely, doomed to spend the rest of their sad, sorry lives waiting for a thread that doesn't exist (it won't even wake up for EINTR, unless this kills the program).

This Blog

By the way, this blog could be viewed as a continuation/expansion of this earlier one I started which quickly went stale, I think mainly due to its scope being too narrow. Or maybe I just have a limited attention span; I guess time will tell.

It's also a place I'll store things I find myself repeating and what a handy reference to, as well as random things (especially code samples) that may be useful to others and that I want to keep. A bit like a public Dropbox (which I highly recommend, by the way).

Some of you might find the previous blog far too geeky/technical - there will be some posts like that in this blog, but there will also be some general/random ones.

The Sea of Abandoned Blogs

There are many abandoned blogs out there. The most poignant I've seen recently may be this one, whose only post ten years ago states that Blogger has given this blogger something to live for.

I really hope he was just kidding...

The Cost of a Degree

I'm doing a degree with the Open University at the moment, and I get really annoyed when my friends enquire about how they might go about a similar endeavour. Not annoyed at my friends because I have anything against them doing the same - the more the merrier, as far as I'm concerned. I get annoyed that I have to tell them that they may have to pay thousands of pounds more than me for the privilege, and all because I snuck onto the system earlier than they did.

For those not familiar with OU degrees, here's basically how it breaks down. You do modules that each carry a certain number of points at a certain level. Undergraduate level 1 corresponds to the first year of a degree, level 2 to the second and level 3 to the third and final year. Usually, you need 120 points from each level for a degree.

So, 120 points of part-time, modular study corresponds to one year of a degree, except you don't (necessarily) do 120 points every calendar year (you can, but you'd better have a lot of free time and/or a penchant for late nights). Anyway, the cost of each course is roughly proportional to the number of points it carries, maybe more if it's a residential course or for certain subjects like law and IT. So whether you study four courses worth 30 points or two worth 60 for a year's worth of study, you'll pay roughly the same for the total 120 points for that level. When I started studying with the OU, the cost for 120 points of study was roughly £1,400.

However, since the university tuition fee reform here in the UK, the cost has gone up drastically. Now you can expect to pay £5,000 for 120 points of study - that's a 350% increase in tuition fees. And remember, that's five grand for a single year's worth of study; to do all three years of a degree, you'd now I'd have to pay £15,000 instead of £4,200.

Luckily, since I started studying at the lower rate I can continue on these lower fees so long as I keep within certain rules like studying something every year and finishing by a certain time. If I'd started studying one academic year later, or if I step outside the guidelines (e.g. by taking a year off studying) I would/will be on the higher rate, and there's just no way I can afford to do that.

"Arrrr!" I hear you cry. "Aye, but there be grants available fer ye if ye wants te study, but ye cannot shell out the doubloons fer it". Well, not for me, since I already have a degree, so I can't get any financial aid for another one. Then again, maybe this is my problem - perhaps I'm being selfish in wanting to broaden my education? Is another degree really just a selfish endeavour I should be made to pay through the nose for? I don't know; I'm just glad I started when I did.