Chess

i think finding bugs that are not caught by stress testing can be very valuable. stress testing doesn't guarantee to hit every scheduling scenario. hitting one particular scenario that breaks in a production environment can be extremely frustrating because there is not a good way to really track the problem down other then looking through the code by hand and hoping to find something. (this excludes programs like CHESS). one chance in thousands or millions is rare but could cause havoc in a system.

OPL paterns

with Pipes and Filters papers. the more recent paper seems to go strait for the heart of the pattern. it gives you the major details and lets the reader fill in the blanks. the earlier paper goes into detail of different variations of the pipe and filter pattern. i don't think this is missing something so much as just a different way to document a pattern. the more recent paper's style encourages creativity. with the first paper you see different varieties and may stop there and use them as is. with the paper this week, the developer needs to fill somethings in to make the pattern useful for a problem.

Reentrancy

i disagree with the author's statement that reentrancy implies thread safety. thread safety requires avoiding race conditions. given the definition thread A and thread B cannot share inputs that are changeable. race conditions require thread A putting a lock on resource X and thread B putting a lock on resource Y and each thread needing the others resource. i recall two threads reading the same location at the same time can lead to unexpected results. these resources are immutable but could cause issues. this is not going to a common case by any means. i can't think of a reason you would need two read locks open simultaneously on separate pieces of "static" data but it does break the author's statement.

BA 14

this chapter details an object oriented language smalltalk. the language has some interesting concepts to it. i think the biggest reason smalltalk never took hold is it has little structure. the lack of structure is one of smalltalks benefits and downfalls. as a programer i feel more comfortable with more structure. that being said too much structure is also a bad thing. strongly typed languages seem to have the idea balance. smalltalk can do everything that C++ or Java can do. the difference is Java or C++ hands you the constructs for loops and conditionals they are there is smalltalk but are built from smaller pieces of the language. this gives smalltalk a lot of power and some advantages but also makes programers shy away from using the language.

relopper

i think relopper could still be useful but not as much as it once was. the paper's motivating example shows a good use for the program. if there is existing code that is structured as a loop then it could be much easier to convert the code to a parallel loop then to a threading type solution. that being said. if i were designing the program to be parallel from the beginning i would probably not choose a parallel loop as the main design choice. so the idea seems good for converting exiting code to parallel if there is not time or money for a complete rewrite.

BA 13

problems that lend themselves to procedural solutions tend to problems that have linear set of steps to solve the problem. an example would be following a recipe from a cookbook. the same steps are followed in the same order.

object oriented solutions start to shine when the order of execution of the individual operations is determined at run time.

refactoring sequatial Java code for parallelism

one major advantage of having libraries built for parallelism is easy of programing. programers don't need to completely familiar with parallel programing to use the libraries. they will need some knowledge parallel programing still to know when to use the library. it also helps programers not reinvent the wheel every time they want to do something in parallel.

the only major disadvantage i can see is behind this type of idea is. that program will probably not be as efficient then it could be if the parallelism was built for that program

BA 12

i agree completely analyzing a problem before any work is done on design or programing is a very good idea. the problem is often times requirements or underlying software changes mid implementation. one sign of a good architecture is being able to adapt when requirements change during development. I'm no expert on KDE by any means but perhaps if KDE's architecture was more modular it may not have required a huge rewrite when QT 3 became QT 4. that's then easier statement to make then to actually accomplish. it's an example of a change that could never really be accounted for.