Currently Reading

Go get it if you havent already. If possible, read it along with this

IT Project ROIs

This post by Andrew McAfee makes for very interesting reading - - the topic being the age old question - ROI on IT investment. Having faced the silliness and reductionist approach employed by most customers, this is much more in sync with my personal "some things in life cant be quantified". more holistic viewpoint. Go check it out

one of my random penned lines

I am no great writer - on the rare occasions I do put down something, the theme is similar to the one expressed below. Wrote this last year ( I think ! )

above I soar
my wings spread
the winds rushing past
in this freedom I glory
the vast expanse
brings in to focus my minuteness
and by being part of this infinity,
i rid myself of my smallness
how I wish i was you - winged one;
one with emptiness and solitude
not for you the ego and the facade
no envelopes or cocoons to hold you
to be able to fly in to this little apartment ledge
and talk to pretty eyes on a whim
u would probably say - because you want, you cant fly
that is what holds you down my friend
while i sit here with clear head and calm smile
talking to the one you desire to be with
let go and you shall be
holds out his claw and asks - can i set you free ?

A Muse on Learning

This blog is a pretty good one for information which is of immediate use. Focuses on technology as the enabler for better teaching (and hence education).
While I am all for any improvements that technology can bring, I am frustrated with the bigger issue at hand. Learning needs teachers to have wisdom. and wisdom often has little correlation with knowledge (of the information kind). Living in a society as it exists today, the sensory overload and the race to be bigger, better, richer; for action does not portend very well to a wiser world. Here is where a Gurukul kind of system; techniques like the one espoused by Vipassana offer some hope.
If anyone has some experience with Gurukuls and Vipassana, please write in.

Small Rant on buzzwords

One of the things that makes me stay away from a lot of so called technical discussions is the inane, moronic usage of acronyms, buzzwords and talk about things which are in fact simple. Now, I can understand a few people using high falutin words as a mechanism to hide their ignorance - how did this phenomenon become so prevalent ? The disease is endemic - whether it be our industry or fields like the life sciences.
Cut out the BS folks - wil save you a lot of breath as this technique of meditation tries to tell you.
Current peeves - Web 2.0, AJAX. Long running hate list - SOA, component, architecture, scalability, reusability. Excuse me while i go and barf some.
One reason why i love environments such as this one. Clean, precise, beautiful and expressive. Almost better than sex is how I describe the experience.

Java VM black magic

This makes for some interesting reading. My question to Sun is - why the heck dont you document some of these things ? Would help some of us when dealing with esoteric issues and searching for solutions.

Java Threads Monologue

Java Threads: The Hand-Off
Traditionally, one of the most difficult (or even impossible) parts of multi-threaded programming was the hand-off, the coordinated transfer of control from one thread to another. Let's build an example using a queue:
On Thread-A, application code asks a Queue to add() a Task for Thread-B to perform.
The Queue, which is performing the add() on Thread-A, places the Task into its list of tasks, and notifies Thread-B.
Thread-B wakes up, and asks the Queue to take() the next Task.
Well, that's pretty simple. Except it doesn't include any thread safety. So, let's introduce the concept of synchronizing on some object. Synchronizing, in computer terms, means to obtain a specific monitor (or semaphore) that only one thread can hold at a time. Think of it as the key to the bathroom door at the gas station on the side of the highway. The owner wants to make sure that either no one is in the bathroom, or one customer is in the bathroom, so a lock (monitor) is placed on the bathroom door and only the customer that gets the key (of which there is only one) can get in. So let's rewrite the above:
Thread-A synchronizes on (obtains the monitor for) the Queue.
On Thread-A, application code asks a Queue to add() a Task for Thread-B to perform.
The Queue, which is performing the add() on Thread-A, places the Task into its list of tasks.
As part of adding the task, the Queue notifies Thread-B that a task is queued.
Thread-A releases the monitor for the Queue.
Thread-B wakes up.
Thread-B synchronizes on (obtains the monitor for) the Queue.
Thread-B asks the Queue to take() the next Task.
Thread-B releases the monitor for the Queue.
Thread-B executes the Task.
Thread-B checks to see if the Queue is empty, and since it is, it goes back to sleep, waiting on the Queue for the next Task.
(If you're the smart kid with the thick glasses that knows that the above is incorrect, please put your hand down and wait patiently.)
Without going into a lot of details, because I know I'd get them all wrong, the above is similar to how we were forced to do multi-threaded programming on Windows (WIN32) in C++ in the mid-90s. It has a problem, though. There are "gaps" in the hand-off.
So what's a hand-off? Rugby and (American) Football players know quite well that one of the most dangerous times in terms of "protecting the ball" comes when one player gives it to another. Similarly, in a relay race (track & field), each runner must hand the baton to the next, and it is the most dangerous part of the race for a runner, in that time can easily be lost in a bad transfer, and a team that drops the baton will surely lose the race (see the Berlin Olympics, 1936, if I remember one example correctly.)
Similarly, for one thread to pick up responsibility from another, there must be a hand-off. That means that both threads must have some overlap in their ownership. To prove the problem in the above execution, just imagine many tasks being added, and tasks being taken off for execution in parallel, and then suddenly no more tasks are added. Every once in a while, Thread-A will add() a Task to the Queue and notify Thread-B, and Thread-B will not get the notification, because it wasn't yet waiting for the notification. This will cause that Task to "stick" in the Queue until someone adds another Task. So let's re-write it again:
When Thread-B starts running, it synchronizes on (obtains the monitor for) the Queue.
Thread-B checks to see if the Queue is empty, and since it is, it goes to sleep, waiting on the Queue for the next Task. (Note that Thread-B never released the monitor on the Queue.)
Thread-A synchronizes on (obtains the monitor for) the Queue. This is permitted because, while Thread-B holds the monitor for the Queue, it is explicitly waiting on the Queue, which means it has given permission for another thread to obtain the monitor for as long as Thread-B is waiting.
On Thread-A, application code asks a Queue to add() a Task for Thread-B to perform.
The Queue, which is performing the add() on Thread-A, places the Task into its list of tasks.
As part of adding the task, the Queue notifies Thread-B that a task is queued.
Since Thread-B is waiting on the Queue, through which it has just been notified, it (Thread-B) is awoken.
Thread-B is supposed to own the monitor for the Queue; since it is still taken by Thread-A, Thread-B is blocked from finishing the "wait" until the monitor becomes available.
Meanwhile, Thread-A releases the monitor for the Queue.
Thread-B now is able to re-obtain the monitor for the Queue, and thus can finish its "wait" and start running again.
Thread-B asks the Queue to take() the next Task.
Thread-B executes the Task.
Thread-B checks to see if the Queue is empty, and since it is, it goes back to sleep, waiting on the Queue for the next Task.
Now, the cycle is complete, because Thread-B now is in a steady state such that it only will go into a wait if there is nothing in the Queue, and if it is certain of that (even as it goes to sleep) because the monitor is not released until Thread-B is actually set up in that "wait" state. Here is an example of the Queue's take() operation that Thread-B performs:
public synchronized Runnable take()
        throws InterruptedException
    {
    // wait for tasks to be added if there are none already there
    while (getList().isEmpty())
        {
        wait();
        }

    // return the first task to be executed
    return (Runnable) getList().remove(0);
    }
From the point of view of Thread-A, when it obtains the monitor for the Queue, it knows that Thread-B is in a state in which it will hear the notification that something has been added. Here is an example of the Queue's add() operation that Thread-A performs:
public synchronized void add(Runnable task)
    {
    // enqueue the task
    getList().add(task);

    // tell the waiting thread to process the task
    notify();
    }
The main thing to notice is that the wait() and notify() methods can only be used on objects for which a monitor is already obtained. And simply, that is the secret behind the safe hand-off.

Starting a blog for the umpteenth time - hope to actually follow through and post things this time around This blog is intended to be randomly distributed amongst one or more of the following - What is education - What is knowledge - Technology (Smalltalk, Squeak, Open Source) - The Human Mind Lets see where all this leads to