Archive for January, 2009

On Abandonment

Tuesday, January 6th, 2009

In philosophy this term means the absence of sources of external ethical authority (*). In software when something is abandoned it has lost control or its referent lost the last reference to it, for example, abandoned threads, processes or data blocks. The latter usually known as heap or pool leaks. File abandonment is frequently the source of user frustrations when they are not able to find why there is not enough space. When we find something that doesn’t have external referents we know that the object has been abandoned. Thus we understand that we cannot say that an object is abandoned when looking at it from outside the containing system, we must look within that system, similar to an existentialist threatment of the concept of abandonment when someone must reflect to find an ethical authority and values.

(*) The Oxford Companion to Philosophy, 2nd edition, p. 1

- Dmitry Vostokov @ SoftwareGeneralist.com -

Reading Notebook: 06-Jan-09

Tuesday, January 6th, 2009

Comments in italics are mine and express my own views, thoughts and opinions

Developer’s Guide to Debugging by M. Wloka, et al.:

Test-driving debugging tools (p. 14) - I’ve seen many times indeed when engineers advised on the phone to collect information using certain tools but didn’t try those tools themselves…

Golden output (p. 16) - an output to compare to, reference output

The notion of common bugs that are easily and readily reproducible with test cases (p. 18)

Idealist heisenbug (p. 19) - a bug stemming from invalid optimization code

Secret bugs (p. 20) - I’ve seen that many times when customers do not send crash dumps due to security reasons. If this is because they cannot inspect binary contents for potential information leaks I devised a way to instruct a debugger to output textual log files with information relevant for at least problem identification. 

Concurrent Programming on Windows by J. Duffy:

Handcrafted semi transactional system, importance of state in-the-small and shared memory dependance (p. 13) 

State management: isolation | immutability | synchronization (p. 14)  

Control vs. data synchronization (p. 14)

What is a state? (p. 15) - I define a state as an memory snapshot at a given time where memory is taken in a broad sense including processor(s) state as well

The transitive nature of state sharing, data privatization and publication (p. 15) - From Windows kernel perspective everything is shared

A reference to escape analysis techniques and ownership types (p. 19)

Critical region as a simulation of atomic r/w not possible in hardware (p. 21)

- Dmitry Vostokov @ SoftwareGeneralist.com -

Reading Notebook: 05-Jan-09

Monday, January 5th, 2009

Comments in italics are mine and express my own views, thoughts and opinions

Developer’s Guide to Debugging by M. Wloka, et al.:

The notion of debugging opportunities - the flow of opportunities to debug from earlier macro instrumentation using source code preprocessing techniques to run-time debugging tools (p. 6)

The notion of debugging breaking personal relationships (p. v, foreword by A. Zeller)

Solution-oriented way

13 rules extend 9 rules of Agans

Rule 3: Simplify the Test Case (p. 9) - Very important in postmortem debugging when someone collects data for you

Rule 4: Read the Right Error Message (p. 9) - Good rule for postmortem debugging too

Rule 6: Separate Facts from Interpretation (p. 10) - Good one

Side-by-side debugging (pp. 11-12) - very important in real life: ETW-based CDF traces from normal and problem scenarious

Rule 8: Match the Tool to the Bug (p. 12) - psychology of debugging

Rule 10: Keep an Audit Trail (pp. 12-13) - for example, logging in WinDbg

Concurrent Programming on Windows by J. Duffy:

Why concurrency? (pp. 3-4) - one reason is missed: to understand memory dumps, traces and logs better - the view from software technical support

Natural scalability: latent -> actual concurrencly during the course of software evolution (p. 5). Some degree of inherent latent concurrencly in programming languages constrained by stylistic habits (p. 5)

“Concurrency begins with architecture.” (p. 6) - merits a new quotation

Decomposition of programs into agents (roughly: entry points interacting asycnronously with envorinment), tasks and data (pp. 6-7)

Architecturing to ease the synchronization burden (p. 7)

Natural domain parallelism (pp. 8-9)

- Dmitry Vostokov @ SoftwareGeneralist.com -

An Attempt to Revive this Blog

Monday, January 5th, 2009

I admit that this blog needs a revival. I haven’t been writing posts since September and my multi-reading techniques failed. It doesn’t mean that techniques are bad, it means that multi-reading needs a reader process and good scheduling. Therefore, in 2009 I change my reading techniques and introduce a reading notebook or journal on this blog. Ideally the notebook will record the most important stuff that I learnt or paid attention to during the day or the previous day while reading software engineering books.

- Dmitry Vostokov @ SoftwareGeneralist.com -