Pitfalls of using threads

livejournal's cpp community had a post on multi threading with c++, which got me reading on this.

The pitfalls with multi threading
- thread safe functions/non re-entrant functions
- deadlock
- race code
- pitfalls seen especially with C++ code (making initialization routines thread safe etc)

Boost.Threads (a little outdated article per the issues discussed still are a part of multithreading environment)
http://www.ddj.com/cpp/184401518

http://www.boost.org/doc/html/thread.html#id1710137

Pthreads
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html

Testing and debugging is highly non-deterministic in a threaded environment, which adds to the difficulties.

Read to know more!

XCode 3.0 Instruments

XCode 3.0 has some exciting stuff introduced- Instruments. Read more on this:
http://www.apple.com/macosx/developertools/instruments.html

Mac OS 10.5

I have been searching for information on Mac Os 10.5. Although there is a lot of scattered information, there is not a single site which gives an overview (technically) of the changes. There is a lot of information on the product/user experience stuff, but hardly any take on the development aspects.

OS 10.5 with 64-bit compatibility: This is pretty encouraging to read. One doesn't need to have any driver/device changes for 64-bit. And 32-bit applications work smoothly too. Also, it follows LP64 model, so Unix 64-bit apps can be ported easily.
http://www.apple.com/macosx/technology/64bit.html

Talking about Unix, OS 10.5 claims to be Unix certified. So any/all unix apps will run on Mac 10.5 as-is, without "any" change!
http://www.apple.com/macosx/technology/unix.html

File system event APIs.. I almost thought this could be used as Kauth is used, before I read it completely. Nevertheless a good feature:
http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/TechnologyOverview/chapter_3_section_1.html#//apple_ref/doc/uid/TP40005289-CH3-SW1

However, I found kernel queues, which provide notifications for most events like Kauth does! Need to see, how far we can go with this.. also whether it caters to our purpose better than Kauth. One thing that I see as a plus here is that it gives notification for exit, fork as well.

http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/KernelQueues/chapter_6_section_1.html#//apple_ref/doc/uid/TP40005289-CH5-SW2

This link I found, was a little less user oriented than others:
http://www.informationweek.com/news/showArticle.jhtml?articleID=202802284&pgno=1&queryText=

OS 10.5 as a server?
http://www.informationweek.com/news/showArticle.jhtml?articleID=202801226&pgno=1&queryText=


Till, I find some more information on this, Ciao!

DTrace on Mac

In my search for some help on tracing calls, I found this interesting link:
http://www.mactech.com/articles/mactech/Vol.23/23.11/ExploringLeopardwithDTrace/index.html

ktrace for some reason, isn't providing us the information needed for tracing the shutdown call. Attaching to the process using debugger also resulted into nowhere as the stacks were too many to analyze and we couldn't really nail down the problem.

Some interesting snippets of this link:

You interact with DTrace by writing small programs in the D programming language. These D programs can be saved in text files and run like shell scripts, or they can stretched out right on the command line for quick, ad-hoc use (or if you simply want to impress your friends). An example D script that totals all the system calls made for each process on the system is shown in Listing 1.

Listing 1: syscalls_per_proc.d

Totals up all the system calls made for each process

syscall:::entry
{
  @[execname] = count();
}

.
.
.


And this:

File activity

It can be enlightening to see which files are accessed on a system. For example, you may see that Foo.app is frequently writing to some file, or maybe that Bar.app is calling stat(2) on a log file every 10ms. This information can help you debug your own programs, or perhaps better understand the system in general. Below we use a small D script to print out the name of each file as it's opened.

$ sudo dtrace -s /dev/stdin
syscall::open*:entry
{
  printf("%s %s", execname, copyinstr(arg0));
}
^D
dtrace: script '/dev/stdin' matched 3 probes
CPU     ID      FUNCTION:NAME
 0  17584      open:entry Finder /.vol/234881026/562669
 0  17584      open:entry Finder /.vol/234881026/562669
 1  17584      open:entry iChatAgent /Users/jgm/Library/Caches/...
 0  17584      open:entry iChatAgent /Users/jgm/Library/Caches/...
 1  17584      open:entry iChat /System/Library/PrivateFrameworks/...


^C

This script sets a probe at the entry to all system calls having names beginning with "open". DTrace tells us that our probe description matched three probes. They are: open, open_extended, and open_nocancel. Our action statement prints out the name of the process (execname) that caused the probe to fire, and the first argument (arg0) to the function that matched the probe. Notice that we need to use the copyinstr function here rather than just printing arg0 directly. This is because D scripts execute in the kernel's address space, but the pathname argument to open is stored in user space. We could also modify our D script so that it shows us which files are accessed most often, as follows.

$ sudo dtrace -s /dev/stdin syscall::open*:entry { @[copyinstr(arg0)] = count(); }


...



Although Apple provides no documentation for this, Sun systems has sufficient docs on this.

And oh yes, this article is also courtesy - Greg Miller.

Mac World

When we initially set out to work on Mac, we Greg Miller's posts helped us a lot. Here are a few links to his blog which are useful for a newbie:

Command line building on KEXT
http://unixjunkie.blogspot.com/2006/12/kernel-extension-by-hand.html


Understanding lists and queues. Vishal would have loved to read this, though getting to understand it himself, must have been more satisfying!
http://unixjunkie.blogspot.com/2006/12/lists-and-queues.html


Sachin had a hard time figuring out a solution for this problem of width that ps assumes. A quick look at the reason for this strange behavior.
http://unixjunkie.blogspot.com/2006/03/strange-difference-in-ps-output.html

Mac UI musts - Command line processing of Cocoa:
http://unixjunkie.blogspot.com/2006/07/command-line-processing-in-cocoa.html

Read more on unixjunkie to know more about small nitty gritties that help a Mac newbie!

Better Explained

A must read for all - betterexplained.com. Truly, all the concepts here are explained with such lucidness that every word written here is worth its weight in gold!

Do read it, for cool explanations on interesting topics.

Reason for this blog

I learn a thing or two in my chosen area of work, almost daily. But somewhere down the line, the learning gets lost. This blog is an attempt to record my daily learnings (ok.. not that frequently :)) so that I can quickly retrieve it when needed and also to share my learnings (while earning) with others!

Hope to see a lot of posts from me!