Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Monday, 26 August 2013

Multithreaded programming

In multithreaded programming, a thread is sometime required to block until some condition is true. In thread systems pre-dating Java, this mechanism is generally called "condition variables" and corresponds to a separately allocated object. For example using the pthread library, you do create and use a condition variable like this:
pthread_cond_t count_threshold_cv;
pthread_mutex_t count_mutex;
pthread_cond_wait(&count_threthold_cv, &count_mutex); // atomically unlock mutex while waiting
phtread_cond_signal(&count_threthold_cv);
When locks and condition variables are used together, the result is called a monitor:

  • A collection of procedures manipulating a shared data structure.
  • One lock must be held whenever accessing the shared data
  • One or more condition variables used for waiting.
In C#, there is no separate type for the condition variable. Instead every object inherently implements one condition variable, and the "Monitor" class provides static "Wait", "Pluse" and "PulseAll" methods to manipulate an object's condition variable. They are used together with lock or Monitor.Entor and Monitor.Exit.
public static KV GetFromList() {
  KV res;
  lock (typeof(KV)) {
    while (head == null) Monitor.Wait(typeof(KV));
    res = head; head = res.next;
    res.next = null; // for cleanliness
  }
  return res;
}

In C# every object also inherently implements a mutual exclusion lock.

Tuesday, 22 May 2012

Runtime exceptions

In Java, RuntimeException is not checked. Runtime exceptions represent problems that are result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in anyway. Such problem include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and illegal arguments exceptions. It is common practice to throw RuntimeException when the user calls a method incorrectly. For example, a method can check if one of its arguments is incorrectly null. If it is, the method might throw a NullPointerException, which is an unchecked exception. For other kinds of incorrect arguments, the method can throw IllegalArgumentException.

The bottom line guideline is: if a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

Any Exception (checked) that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them.

Reference: http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

Friday, 12 August 2011

Notes on Robert Martin interview by the Pragmatic Bookshelf

Podcast: http://pragprog.com/podcasts/show/32

1. Programming is a craft and you do it for the shear love of it. Why would you want to do anything else? Why don't you perfect it. If you love doing it, why changing to another field like management?

2. Learn a new language every year. Clojure is an interesting language to know. Learn functional languages.

3. Corporate languages like Java and C# will become legacies.

4. SOLID: principles of organizing objects in a object oriented language: what should be in a class and what the relationships between objects ought to be.
Single responsibility, Open closed, Liskov substitution principle, Dependency inversion, interface segregation

5. TDD

6. The Structure and Interpretation of Computer Programs - by Abelson and Sussman