Friday, October 15, 2010

Double Checked Locking And Java Singletons

I read this article by Bill Pugh on why the double checked locking idiom does not guarantee thread safety in Java Singletons. That article taught me a lot of new things, and to be honest, I had to re-read that article at least a couple of times to partially understand it :-)

I recently created a presentation to make at DevCamp on this topic. What follows are my slides and an explanation of each slide. I hope you enjoy this presentation and find it useful.


slide 1:
In this presentation I will discuss the double checked locking idiom, and explain why it does not work to provide thread safety to Java Singletons. I will also talk about how using volatile fields will fix the problem in JDK 1.5 onwards.

slide 2 (Singleton):
Many of you might already have used the Singleton design pattern. In case you have not, here is a brief description of what Singletons are. The Singleton pattern is used when we want to ensure that there is only one instance of a class per something. In most cases, the something is 'JVM - Classloader' combination. So, in such cases we want to ensure that there is only one instance of the Singleton class in the JVM-Classloader. But we are not restricted to this. We may need only one instance of the Singleton per Session, or per Request, or per anything else that makes sense in the software you are making.

It is clear that we want to control the instantiation process of the Singleton class. To do this, the first thing we do as shown in the example is to make the constructor private. With the constructor private, no other class can create an instance of this class. OK, so how will we create any instance of this class? We provide a public static method called getInstance() which will return an instance of this class. We will also use a private static field called instance to hold the one and only instance of this class. Since we control the getInstance() method, every time it is invoked we will return instance. The first time however, instance will not be initialized, so we put a null check in getInstance() and instantiate instance if it has not already been instantiated. Hence forth we will always return a reference to instance. This way we ensure that only one instance of our Singleton will be ever created (the one we save in the field called instance).

slide 3 (Is This A Safe Singleton?):
Look at the class carefully and ask yourself "Is this Singleton safe?"

slide 4 (The Singleton is not Threadsafe):
If you have looked at the class carefully, you will realize that the Singleton is not thread safe. This slide shows why it is not thread safe. Imagine that a thread T1 invokes getInstance(). If an instance of the Singleton has not been created till now, then instance will be null, and T1 will enter the if block. Now imagine that T1 gets pre-empted, and thread T2 also calls getInstance(). Since T1 got pre-empted before it got a chance to create instance, the reference in instance is still null. So T2 will also enter the if block. Now if T2 does not get pre-empted then it will go ahead all the way where it will create an instance of Singleton, and probably even use it. Now when T1 is resumed, unfortunately it does not know that the Singleton has already been created, since it has already gone past the null check. T1 will also happily create an instance of our Singleton, thus breaking the Singleton pattern. We have 2 instances of the Singleton which is simply not allowed.

slide 5 (Let;s Make It Threadsafe):
Alright so we need to make the getInstance() method thread safe. The simplest way to do this is by making it synchronized. Once it is synchronzied, only one thread will be allowed to enter the method at a time, and we will never get into an issue where we end up having multiple instances of the Singleton.

slide 6 (That Was Expensive):
Making a method synchronized is expensive. A thread executing a synchronized method must acquire a monitor before it can invoke the method, and release the monitor after executing the method. This takes time and CPU cycles. In early JVM's (I have read somewhere), the time to invoke (not execute) a synchronized method was as much as 100x the time taken to invoke a non synchronized method. I think this was improved in later JVM's where it was about 15x. I recently did a quick test on JDK 1.6, and the number I got was 2x. Regardless of how much slower it is, it is definitely slower, and programmers always want to make their code fast.

slide 7 (Let's Use Double Checked Locking):
Some very smart programmers came up with the "double checked locking" idiom to relieve the code of this expensive operation. What we really should have done, is only synchronize the code which instantiates the Singleton, and not the entire method. That way we incur the expense of the synchronized block only once, when the Singleton needs to be created, and all subsequent times (instance == null) will always be false, and the instance will be returned to the calling code. We put a second check inside the synchronized block, because it is possible that a thread could get pre-empted just after the first null check, but before it enters the synchronized block. In such a case, if another thread enters this method, and goes all the way to creating the instance then the first thread will not know of it and will create a second instance. To prevent this, we put another check in the synchronized block.

So this is a pretty smart solution. We eliminate the synchronization on the method, thus eliminating synchronization on the main path.

slide 8 (Will It Work?):
The solution described in the previous slide (double checked locking) is a pretty smart solution. But it does not work.

slide 9 (Why?):
There are two reasons why it does not work. The compiler as well as the processor (as well as the JVM) may reorder instructions if they feel it might be more optimal. Off course they cannot randomly reorder instructions but they could if they can prove that the reordering will maintain as-if-serial semantics. However, this is not the only reason. On a multi-processor system, each processor has it's own memory cache. The cache is not always synchronized with main memory immediately. This can cause a write to a memory location to happen in the local cache, which will not be visible to other threads which could be running on other processors. Even if the writing thread does flush it's local cache, it is still possible that another thread which reads that value, may not have pulled in most recent values from the main memory into it's local cache. This can cause a situation very similar to reordering where the effect of a write is not visible to another thread that is reading that variable's value.

slide 10 (instance = new LoneRanger(””) != Atomic operation):
If you look at the example in slide 7, you might think that the statement below is an atomic statement.
instance = new LoneRanger();
But that is not the case. For the sake of simplicity this slide shows the statement above broken into 2 operations. In the first part, an instance of the class is constructed, and in the second part a reference to that instance is assigned to the variable instance.

slide 11 (Compiler Reordering):
Now what if the compiler reorders the instructions in such a way that the field instance is assigned an uninitialized block of memory (created for the class LoneRanger), and then the constructor of LoneRanger is invoked in the second step.

slide 12 (Compiler Reordering Pseudocode):
This slides shows pseudocode to understand the effect of compiler reordering on the double checked locking code. The code in the synchronzied block which instantiates our Singleton is broken into two steps: assignment, and initialization, where the assignment happens before the initialization.

Now imagine thread T1 enters the getInstance() method, enters the synchronized block and executes the statement which assigns the block of memory allocated for LoneRanger to the variable called instance. If T1 gets preempted and thread T2 enters getInstance() then T2 may see a non null value for instance. Thus T2 will actually be returned an initialized object of LoneRanger. This could cause all sorts of bugs in the software.

So in the first problem described a few slides back, we ran into the issue of having multiple instances of our Singleton, which we attempted to fix with the double checked locking idiom. However, this introduced the issue where a thread might be given a reference to an uninitialized instance of the Singleton.

slide 13 (Can We Prevent reordering):
Programmers never give up :-) When an even smarter programmer was explained this problem, he remarked "so let us prevent reordering and our problem will be solved !". Ok let's try that, but how do we prevent reordering? Well there is something called a memory barrier, which may help us. Instructions cannot be reordered across memory barriers (although they may be reordered within a memory barrier). Let's see if we can introduce memory barriers to prevent the reordering that's been giving us such a hard time till now.

slide 14 (Memory Barrier):
A memory barrier is a low level (at the level of the processor) construct which is used to create a fence around instructions. Instructions which are fenced inside a memory barrier cannot be moved out of the fence, and memory caches are also synched with main memory when a memory barrier is encountered.

slide 15 (Memory Barrier):
This slide explains memory barriers with an illustration. In this slide notice that instructions (instr2, instr3, & instr3) are fenced with the memory barrier. Because of the semantics of a memory barrier these instructions can never be moved out of the barrier, but they may be re-ordered within the memory barrier. We can also see when the memory barrier is entered the local processor cache is invalidated and latest values are read from the main memory, and when the memory barrier is exited then the local cached is flushed and the main memory is updated with the latest values.

slide 16 (Memory Barrier):
Because memory barrier is a low level construct, there is no way to explicitly create one in a high level language like Java. However, the synchronized keyword in Java implicitly creates a memory barrier. Before I read this, I had no clue that synchronization in Java is anything more than a mutex. But I read somewhere that when a monitor is obtained an memory barrier is also created and when a monitor is released the memory barrier ends (this is my understanding, please correct me if this is wrong).

slide 17 (Double Checked Locking With Memory Barrier):
The fact that assignment and construction of our Singleton could be reordered created the issue of potentially having an uninitialized Singleton. We want to ensure that the reordering does not happen. For that let us separate the construction and assignment with a memory barrier and put the assignment after the construction. We do this with 2 synchronized blocks and a temporary variable. In the inner synchronized block we will initialize the Singleton and assign it to a temporary variable. We don't care if this is reordered, because the class variable instance will still be null which will prevent another thread from getting an initialized instance of the Singleton. Then we assign the reference to the temporary variable to the class variable instance. This happens outside the memory barrier. So by employing a memory barrier we are hoping to maintain program order in the execution of instructions. Again a very smart solution, but unfortunately this does not work either.

slide 18 (Monitor Exit Semantics):
The semantics of monitor exit specify that everything that happened before the monitor exit should happen before it, which means that nothing from the inner synchronized block (where we instantiate the Singleton) will be moved out of the inner synchronized block, however, it does not mean that something will not be moved from outside of the block to within it.

slide 19 (Monitor Exit Semantics):
This slide explains monitor exit semantics with an illustration. As we can see inst2 and inst3 are within the memory barrier. Neither of them will be moved out of the block, but inst4 which is out of the memory barrier may be moved in the barrier.

slide 20 (Double Checked Locking With Memory Barrier):
This slide shows the code where we tried to use the memory barrier. But this time we show the code with a potential reordering. With the statement instance = tempInstance inside the memory barrier it could be further reordered to the point before the actual construction of the Singleton, bringing us back to the same problem.

slide 21 (OK So What The Hell Will Work ?):
Alright enough of playing around... not I am getting a bit edgy.... just tell me what the hell is going to work. Is this what you are saying to yourself? Java has a special modifier called volatile. We can use these fields to help us with the Singleton.

slide 22 (Semantics of volatile):
The volatile modifier is used in Java to communicate state changes between threads. This slide explains the semantics of volatile with an illustration.

The code on the left shows a class which has two methods: writer() and reader(). The writer() method writes values of variables x and v to memory, and the reader() method reads values of x and v from memory. Imagine that both these method will be called by different threads T1 and T2, running on different processors P1, and P2. Each processor has a local memory cache and off course there is also the main memory. The variable v is volatile and x is not volatile.

When thread T1 executes writer() we are guaranteed that the instructions will not be reordered because v is volatile. We are also guaranteed that when thread T1 exits the method, processor P1's local cache will be flushed to main memory, which means that the value of x as well as v will be visible to other threads. When thread T2 executes the method reader(), it first reads the value of v, this is going to invalidate the local cache of P1, and fetch the latest values from main memory. This ensures that it sees the latest values (which in this case were the ones written by T1 when it called writer()) of v and x.

So this slide explains the semantics of volatile and how volatile may be used to ensure that instructions are executed in program order and also ensure the visibility of writes by one thread by another thread.

slide 23 (Double Checked Locking With Volatile):
This slide shows our old and well known example which uses double checked locking, but this time with a little difference. This time we have made the variable instance a volatile field. Making it volatile will ensure that the write to initialize the LoneRanger object and the assignment of that instance to the field instance will not be reordered. This elimitaes the problem of seeing an uninitialized Singleton object.

slide 24 (Singleton With Static Initializer):
After doing all these coding gymnastics, in this slide we show a solution which is probably the simplest solution for creating a thread safe Singleton. Instead of instantiating the Singleton in getInstance(), we use a static initializer, which will instantiate the Singleton when the class is loaded. Java semantics ensure us that all static fields of a class will be completely initialized before the class is available for use. This means that the field instance will be properly initialized before anyone makes use of the class to get an instance of the Singleton.

slide 25 (Singleton With Static Initializer):
In this slide we understand the pros and cons of using a static initializer. Even though using a static initializer is the simplest solution, it is possible that everything the Singleton needs to initialize itself may not be available when the class is loaded (which causes the static initializer to be invoked). It is also possible that the Singleton may be eagerly loaded, which may result in greater loading time for our application, something that may be undesirable if instantiating the Singleton is an expensive operation.

slides 26, 27, 28 (Summary):
In these slides we summarize the main points covered in the presentation till now.

slide 29 (Resources):
Links to some very good and relevant articles, including my favorite article by Bill Pugh.

slide 30 (Thank You):
Thank you for your patience. I hope you found this presentation useful. One more thing before signing of - many people (here and here, but someone also disagrees) consider Singletons to be evil...

Saturday, July 24, 2010

DIY Masters in Computer Science

Since my formal education, a lot of advances have taken place in software development. I have been able to keep up with a few with regular reading and practice. But a lot of this learning has been a bit random, and as a result a bit dissipated as well. I feel like I want to engage in continuous learning, in a more organized manner.

Over the years there are several core concepts which I have forgotten because I have not been able to use them in my regular work. I feel like relearning those concepts.

I think the volume and content of both these can constitute a masters course in Computer Science. But I do not want to go back to school. Not because there is anything wrong with school - I had a great time in grad school. But here's why...

I don't want to go back to school because I want to define the courses I want to learn, and not pick up from what's offered.
I don't want to go back to school because I want to be able to learn at my own pace, which at times may be slower than 1 course per semester.
I don't want to go back to school because I do not want to spend a fortune learning stuff which I can learn myself using free resources.
I don't want to go back to school because I would rather create online/social credentials than get a school certificate.
I don't want to go back to school because I want to demonstrate that a person can not only get knowledge but also credentials if they engage in disciplined self-study and leave learning trails on the Internet.

So this time I am doing a DIY (Do-It-Yourself) masters in Computer Science. so I can refresh things I have forgotten and learn new technologies and concepts which have gained importance in recent times, in an organized way.

I did a Masters in Computer Science more than a decade back. Since then, Internet, communication technologies, and social networking, have made it possible for someone to do a similar program all by themselves, using open courseware, and social learning.

By doing this program, I am not only planning to enhance my own knowledge, but am also hoping to show how one can get a Master's education worth of knowledge, and credentials, by self learning, and without spending a fortune. Here's a very brief statement of purpose.


My DIY Learning Process:

I have created a learning plan which outlines at a high level the topics I want to learn. I will study one or two topics at a time, and at a manageable pace, given other work commitments.

Once the topics to learn have been identified, I will identify learning resources, forums, and mentors for that topic.

A very basic study plan is to study the material, and make notes of my understanding, as well as questions and thoughts, I get in my mind as I am learning. I will make these notes available on a special blog. This blog will serve as a personal knowledge base (I can refer to it in the future), as well as a learning trail (for proof of study and understanding).

All the homework I do while I am taking a course will be made available in the public domain. I will either post it on my blog, or if the homework involves coding, on a public open source repository such as Github. I will also do one or more projects to practice the entire body of knowledge as a whole and publish that too in the public domain.

I will also create presentations of what I learn, and make them available in the public domain.

I will connect with mentors who are experts in the topic I am learning. Depending on their time availability I will request them to help me identify gaps in my understanding, and validate my knowledge.

When I have doubts, I will ask questions on Internet forums. If my questions are not answered satisfactorily on the forums, I will refer them to my mentors.

Please visit my learning plan for further details.


Establishing Credentials:

A person can have several reasons for learning. One is for the knowledge (either for the joy of knowing something, or for more practical application of the knowledge), and another for establishing credentials, so someone else may entrust us with work which requires such knowledge. A self learned person may have the knowledge, but may lack credentials to prove it. It is also possible for a person studying in a silo to think he has grokked what he just learned, when in reality he may not have understood the matter properly. To be able to provide proof of knowledge as well as to validate my learning with other practitioners, I plan to engage in what can be loosely classified as social learning.

I will do the following to document my learning and to engage with the community of practitioners, in the hope of validating my knowledge and establishing credentials for what I learn:
  • Answer questions on forums
  • Blog my study notes, and clearly articulate my takeaway from all the lectures I view, or text I read
  • Create presentations and post them on YOUTube, or other video sharing services
  • Publish homework on open source code repositories such as GitHub, etc
  • Request my mentors to quiz me to help me find gaps in my understanding of a topic. I will publish the quiz as audio/video and request the mentor to post their feedback in the public domain
  • Take quizzes and tests wherever possible and economical
So I am leaving these learning crumbs on various places on the Internet, but I need something to bring everything together. Something which can serve as the focal point, or a lens into all my learning. I created a wiki site to serve as the focal point.

Have you been meaning to learn something yourself? Perhaps you can do your own DIY course in whatever interests you. Here is a lens into my DIY experiment.

Wednesday, May 12, 2010

Android apps can run in parrallel (video)

This is the seventh in a series of videos published by Google on Android programming.



In this video the speaker starts an app to track photos his buddy publishes on Flickr. He can keep this application running in the background, so while he is browsing or checking his email, this application will constantly track the photos and notify him if a new photo has been uploaded.

Tuesday, May 11, 2010

Adndroid apps don't have any borders (video)

This is the sixth in a series of videos provided by Google on Android programming.



Index:
00:00 Introduction
00:32 Zebra crossing application
01:35 Library app
02:14 A GeoSocial app which combines user GPS, user created photos, and Compass


My Takeaway:
Android applications do not have any borders. They can use data from other applicatiosns, they can use hardware available on the device such as camera, compass, GPS, accelerometer, etc, and they can also use content from the web API's.

The first application called Zebra Crossing is an application which can pull information from bar codes and QR codes. So if you photograph a product's bar code and give it to the application, it will pull up information about the book from the web. If on the other hand you give it a QR code from the back of a business card, it can extract contact information about that person which you can use to call or send email. The Zebra Crossing app also publishes intents, to allow other applications to communicate with it.

The second application is a library application which uses the "Zebra Crossing" app to add books to your personal library.

The third application, which I found to e really cool is an application which mashes together GPS, photographs, and the Compass to create a GeoSocial application. So here's what it does. Imagine you are on a vacation and want to locate cool things around where you are. You can use this application to find out all the photographs people have taken around that locality. If you find something you like, you can actually locate that thing (which was photographed) on a map and also use the Compass to get there. Cool isn't it?

Monday, May 10, 2010

How to embed the web in Android apps (video)

This is the fifth in a series of videos provided by Google on Android programming.



This video shows how we can use the WebView to create applications that render HTML pages. Along with being able to embed HTML and Javascript web pages in apps, the most exciting thing I found in this view was the fact that the Javascript in a webpage can communicate with Java code and Java code can communicate with javascript. This is really cool.

Sunday, May 09, 2010

Android programming - All applications are created equal (video)

This is the fourth video in the series of videos provided by Google on Android programming.





Index:
00:25 Dianes ringtone app
01:08 App to create a shortcut to anything on the system
01:36 Replacing the home screen (End at 02:17)

My Takeaway:
This video shows that all applications created on the Android platform are equal. Even though I have not done any iPhone development, I believe applications written for iPhone do not have access to everything the way Android applications do. So this is a positive for Android development.

In this video we see how to a custom application can change the ringtone on an Android phone, how another application can create shortcuts to anything on the phone, and how we can also change the 'Home' application.

Saturday, May 08, 2010

Android Programming - API's (Video)

This is the third video in the series of videos provided by Google on Android programming.



Index:
00:00 Introduction
00:16 Android API's
00:24 Location Manager
01:25 XMPP
02:42 Notification Manager
04:08 View System
06:00 Conclusion (Ends at 07:05)

My Takeaway:
In this video the speaker talks about API's provided on the Android platform to developers.

The LocationManager API allows an application to get the location of the device it is running on. This information can be used to register intents, which will inform the user if they are close to an interesting location such as a Ice Cream shop. I can also think of another use. If traffic information is available, then we can also use the location manager to inform us if we are getting close to a high traffic area. Interestingly this API uses whatever information it has to determine the location. If GPS information is available then it will use that, otherwise it will use cell tower information.

XMPP Service is used to send messages to a device. It can be used to send device to device messages, or server to device messages. I think this API can have very interesting uses. It can be used for multiplayer games, and it can probably also be used by trekkers to track each other.

The Notification Manager API provides applications the ability to send notifications to the user on the status bar. My impression is that this API is very well designed. The notification appears on the status bar, such that if a user selects it (using whatever input method available... touch, etc), it will display a preview about the application and notification. If the user is interested, they can further select the notification to go to the application which send it.

The View system provides several view controls help developers make their applications. Interesting controls include a Map control to embed location information in applications, and an HTML control to embed web pages in applications.

Wednesday, May 05, 2010

Android programming - Application lifecycle (Video)

This is the second video in the series of videos provided by Google on Android programming.




Index
00:00 - Introduction
01:00 - How Android integrates apps written by different authors.
07:50 - Conclusion (Ends at 08:16)


This video walks us through a hypothetical use case, where a user opens their email, reads a message which contains a link to some location. The user then clicks on the link, opens the browser and views the location on Google Maps.

While engaging in these activities, the user starts various applications (processes) and also navigates back and forth among them. The video explains how Android manages resources and the application stack so the user can navigate across their apps seamlessly.

My Takeaway
From the video it seems like Android supports a maximum of 4 running processes. One of those processes is the System process, so a user can have at most 3 applications running simultaneously. However, this does not mean that a user cannot open more applications. When the user opens the 4th application, Android will automatically terminate an application, and will also revive it in a known state if the user were to go to it again.

Update:
Ram pointed out that "4 running processes" is purely a number they used in this example. He is absolutely correct. 4 is just an example (perhaps they assumed 64 MB RAM on the phone...). The real number depends on the amount of memory (RAM) available on the phone.

Sunday, May 02, 2010

Android programming - architecture video

I have been getting interested in Android programming, so I went over to their website and found some introductory videos.

Here's the first one with a little index of what is discussed and my take away from the video.



Video Index:
00:0 Introduction
00:40 Linux Kernel
01:09 Native Libraries
03:09 Android runtime
04:13 Core libraries
04:31 Application framework
07:00 Applications
07:25 Application building blocks
09:37 Example of re-using components in Android
12:18 Conclusion and resources
12:48 End

My Takeaway:

Architecture wise the Android platform has several layers:
  1. Linux Kernel
  2. Native Libraries
  3. Android Runtime
  4. Core Libraries
  5. Application Framework
The applications that we make are build on top of the "application framework" layer.

The Linux Kernel was chosen because of it's stability, services, security, and presence of several device drivers.

Native Libraries consist of various components for rendering graphics and fonts (Surface Manager, OpenGL, SGL, Freetype), a lightweight database engine (SQLLite), a browser engine (WebKit), and others.

The Android Runtime consists of Dalvik the Java Virtual Machine created by Google, which is optimized for running on embedded devices which have low resources. Dalvik runs *.dex files which are created by converting *.jar and *.class files. On top of Dalvik are the core Java libraries consisting of things like the Collections, IO API, etc.

Then the Core libraries layer consists of components such as Activity Manager, Resource Manager, Package Manager, Content Provider, Telephony Manager, XMPP, etc.

Android applications typically have 4 building blocks, which applications mayor may not use. These are:
  1. Activities
  2. Intent Receivers
  3. Services
  4. Content Providers
The video ends with an example of how various applications can re-use a photo picker component. So, we may have multiple applications like email, Blooger, etc which may need to select a photo. These applications do not have to write their own photo picker. They just show an "Intent" to pick a photo, and the component which fulfills that intent will be chosen. This binding is done pretty late, so we can actually change the component that fulfills the intent, and then henceforth that component will be used for that intent.

In the next few blog posts I will be embedding more Android videos along with my learnings.

Friday, April 30, 2010

tightvnc with gnome messes up the keyboard mapping

Everytime I run our unit tests, I get Java Swing windows flying across my screen making it impossible to work. A friend suggested that if I ran the tests in a vncclient session, the windows will be contained within vncviewers window.

So I installed tightvncserver and client on my Ubuntu 9.10 machine. When I started vncviewer I realized that the keyboard mapping as messed up, making it impossible to type anything sensibly in the vnc session.

Some searching seems to suggest that Gnome is causing this problem. This page offered a solution of changing VNC's startup file to not fully start Gnome, and it worked for me.

Workaround: I modified my ~/.vnc/xstartup to be:

#!/bin/sh

xrdb $HOME/.Xresources
gnome-wm &
gnome-panel &
nautilus --no-default-window &
gnome-cups-icon &
gnome-volume-manager &
xterm &

Tuesday, April 27, 2010

Java Applet on 64 bit Linux

I have been working on an Ubuntu 9.10 (64 bit system) from some time. I had read some stories of problems running 64 bit Java Applets on 64 bit Firefox, so when I needed to use Applets I did some googling to figure out how to do it.

I came across a couple of posts. Some had different solutions for different versions (3.5, 3.6) of Firefox, and they also wanted me to use IcedTea. The solution I used is outlined here, and it worked perfectly well for me.

Note: You may not have libnpj2.so in the same place mentioned below.

mkdir ~/.mozilla/plugins/
ln -s /usr/lib/jvm/jre1.6.0_12/lib/amd64/libnpjp2.so ~/.mozilla/plugins/

Tuesday, April 06, 2010

Showing lines before and after a grep match

Today I ran running grep on the output of hg log, but only to realize that I wanted a couple of lines before and after the line which matched as well.

I am sure this is common knowledge, but I did not know how to do it, so am sharing it in the hope that someone finds it useful.


hg log | grep --before-context=2 --after-context=2 username


Running the above showed me changeset number, comments etc for all the mercurial changesets committed by the specified user.