reference counting

reference counting can be thought of as a shared lock in many cases. especially in situations where a zero reference event means something.

this is because thinking of a lock this way makes you realize that taking out a reference is simular to acquiring a resource shared. this is important when a function ends up holding resources while the reference is held. this then inherently creates a locking order.

this opens us up to incorrect locking order, just by incrementing a ref count:

thread 1: function A

acquires resource R
waits for refcount X to reach zero : equiv to acquiring SR lock exclusive

thread 2: function B

increments X : equiv to aquiring SR lock shared
acquires R

in the above example it is possible to deadlock both thread indefinately since thread 2 will never get resouce R and thread 1 may never get notified of the zero ref event.

To make this complete we need to remark that a ref count is more like a SR lock that also supports try acquire exclusive. This is best represtented in a referenced object that decrements its refcount in a container classes destructor. And when the ref goes to zero it frees up its associated memory. This is simular to the destructor trying to acquire the SR lock exclusive and if successful freeing up the associated memory.

crazy list of api changes from 2k8-win7:

http://aw.comyr.com/apichanges/2k8SP1-Win7RC.xml

How to enable "Disable Backoff" for t...

How to enable "Disable Backoff" for the search Indexer:

open run dialog: Win+R

type gpedit.msc and hit OK

browse to Administrative Templates\Windows Components\Search

select disable backoff:

And enable it:

Alternatively you can create the DWORD reg key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search\Disable Backoff = 1

 

How to configure hotmail sort order:

 How to configure hotmail sort order:

 

And then select Display contact as:

 

Select the last first option:

FSCTL_GET_VOLUME_BITMAP can be a tricky FSCTL for first time use. In particular the output buffer can be interpretted incorrectly. If your output buffer is not big enough to handle all the requested information you will receive ERROR_MORE_DATA as your return code (as you would expect).

The common mistake is to interpret VOLUME_BITMAP_BUFFER::BitmapSize as the number of clusters covered in the output buffer. However this is not the case. This member variable describes the number of cluster left in the volume from your startin LCN that you passed into the call. The # of valid clusters needs to be calculated from lpBytesReturned. The calculation would be as follows:

ULONG clusters = lpBytesReturned - FIELD_OFFSET(VOLUME_BITMAP_BUFFER, Buffer);

clusters *= 8;

I personally don't like this implementation because it is easy to get this wrong and typically an API which returns ERROR_MORE_DATA with a member describing the # of bytes actually needed suggests that the output data is only valid in its full form. Obviously a bitmap does not fit into this category.