Google Interview Question Software Engineer / Developers
Country: England
Interview Type: Phone Interview
> What is a process and what is a thread?
A process is a part of a program; it has its own execution context, including access rights, memory, open file handles, an own process id and that process id of its parent/creator.
Processes can share memory. If their parent process gets killed, they will be killed, too; if the parent just terminates, the new parent will be the init process.
There are two different kinds of threads: The "kernel thread" is a lightweight process that shares at least its memory with other threads, which makes it a part of the same running program. The "user thread" is a lightweight thread, which can run with other user threads in the same kernel thread. User threads are a design by libraries and programming languages, and are not part of the operating system.
Processes contain kernel threads, which contain user threads.
Processes do not contain other processes but can create child processes.
The first kernel thread /is/ the process, others are some kind of child processes.
User threads are self-sheduled, they have to switch voluntarily, iff they run in the same kernel thread; but they can be designed to be able to migrate between kernel threads. Processes and kernel threads are sheduled by the kernel and can run in parallel on multicore cpus or even on different machines.
> How do you prevent deadlocks?
By designing thought-out, probably using
spin locks, other locks, atomic operations, and STM (Software Transactional Memory) mechanisms.
Contention can occur when two threads inside a program are trying to share a single shared resource, like a buffer or some flag variables. This is prevented by locking mechanism.
Deadlock occurs when one thread is contending for resource held by another thread, which is contending for resource held by the first thread, such that there is a circular chain of dependency. Deadlock can be prevented by taking locks in a particular order. If each thread wants to take more than one locks at any time, it should do so in a pre-defined sequence. This will prevent deadlocks.
good one, I agree on that: locks should be acquired in a particular order for *all* threads to prevent deadlocks.
btw, another common "deadlock pattern" is waiting on a semaphore while holding a mutex, e.g. consider the following:
thread1:
mutex.lock();
sem.wait();
// do some work
mutex.unlock();
thread2:
mutex.lock();
sem.signal();
mutex.unlock();
suppose semaphone 'sem' is initially set to '0'.
Then depending on the order of execution of threads,
it might happen that thread 1 acquires mutex first and hence the semaphore will never be signalled..
Process
- Sam February 06, 2012Each process provides the resources needed to execute a program. A process has a virtual address space, executable code, open handles to system objects, a security context, a unique process identifier, environment variables, a priority class, minimum and maximum working set sizes, and at least one thread of execution. Each process is started with a single thread, often called the primary thread, but can create additional threads from any of its threads.
Thread
A thread is the entity within a process that can be scheduled for execution. All threads of a process share its virtual address space and system resources. In addition, each thread maintains exception handlers, a scheduling priority, thread local storage, a unique thread identifier, and a set of structures the system will use to save the thread context until it is scheduled. The thread context includes the thread's set of machine registers, the kernel stack, a thread environment block, and a user stack in the address space of the thread's process. Threads can also have their own security context, which can be used for impersonating clients.
Found this on MSDN here: h t t p : / / msdn.microsoft.com/en-us/library/ms681917(VS.85).aspx