Clandestine Coder

I recently experienced substantial difficulty trying to install the gtk2 gem on a Ubuntu 16.04 laptop. Attempts to simply run ‘gem install gtk2‘ proved perplexingly fruitless.

Eventually I suspected that while the gem was installed, it may not have been installed within the gem collections for the appropriate ruby version I was using under rvm, since the error was cast from a directory contained within a ‘.rvm’ folder. After some digging, I found that the following command successfully installed the gem under the appropriate ruby version within rvm which I was using:

Working on an OpenMP application I came across an interesting race condition. The application involved iteration over the contents of a matrix, using a for-loop and a second nested for-loop, during which the values in each row were arithmetically modified by an offset proportional to the foremost non-zero value in each column. Within the serial implementation, in the first for-loop, the offset was computed, prior to modification of the values within a given row using the computed offset.

A naive approach to the optimization of the application was to introduce a parallel section within the outer for-loop to perform the arithmetic modification of each value within a given row of the matrix in parallel. This was done by simply by introducing a ‘pragma omp parallel’ section around the contents of the outer for-loop, and a ‘pragma omp for’ section around the inner for-loop.

After running the application and observing that the production of the expected output was inconsistent, I hypothesized that there was likely a race condition in the application. After spending time debugging, I observed that, since the offset was proportional to the foremost, non-zero value in the current row, and that a thread would modify this value, there was a race condition which necessitated the synchronization of the threads in the parallel section after the computation of the offset, in order to ensure that all threads had computed the same offset before proceeding to modify the contents of the matrix using that offset, since one of the threads, in modifying the matrix, would alter subsequent computations of the offset. After the addition of a ‘pragma omp barrier’ which followed the computation of the offset in the parallel section, before the inner for-loop, the application consistently produced the correct result.

I wanted to try using VS Code for a bit instead of Atom. The default clang format settings in VS Code differed from the defaults used by the ‘atom-format‘ package in Atom, which is what I’ve used up until this point. I wanted to use the same formatting behavior in both environments so that I can freely switch between the two in the future as needed.