some OS questions?

[gooddevil]

these are some of the questions that we were given in a paper.
couldnt find satisfactory answers to some by googling. so i am putting them here.if u know pls tell.

1. what do u mean by semaphore convoys?

2. When a process terminates within the critical section what happens. what actions does the OS take in this situation.

3.how many stacks does DOS (single user, single-tasking)use.
a.1 b.2
c.3 d.4

4.what is a virtual processor?

a. a thread b. a kernel thread
c. a user thread d. a kernel supported user thread.

ok thats it.thanx

[Salem]

> 1. what do u mean by semaphore convoys?
No idea - I've heard of semaphores and convoys, but never both together

> 2. When a process terminates within the critical section what happens. what actions does the OS take in this situation.
Are they managed by the OS or the thread library?
Mostly it involves waking up one of the objects (task, thread) waiting to enter the CS
Whether or not that actually involves a context switch depends on the priorities of the thing just leaving the CS and the thing about to enter the CS

> 3.how many stacks does DOS (single user, single-tasking)use.
No idea - my guess is 2 (one user, one interrupt)
There is a config.sys thing which usually goes
STACKS=9
Whether that's the same thing or not I don't know

> 4.what is a virtual processor?
I'd say none of the things you listed.
To my mind, its what the likes of VMWare (http://www.vmware.com/) give you

[gooddevil]

[QUOTE=Salem]>
Are they managed by the OS or the thread library? Mostly it involves waking up one of the objects (task, thread) waiting to enter the CS.
so does this mean that the OS is going to allow the other process to behave as though there is no process in the semaphore, so again they can decide which is the next process to go in.

Whether or not that actually involves a context switch depends on the priorities of the thing just leaving the CS and the thing about to enter the CS.

i actually din get what u meant by this. i think there should be no context switch becoz the process in execution terminated, so there is no question of storing the states of this process. i dont know but is copying a new process for execution called context switching?

ok if u know what convoys are in OS pls share it with me.
thanx

[Salem]

Of course there's the possibility of a context switch. If you don't have at least two tasks/threads trying to access a critical resource (which is guarded by a critical section), its a complete waste of time having a critical section in the first place.

Since you have at least two tasks/threads (one leaving the CS, one about to enter the CS), something has to decide which one runs next. This means either
P1 is suspended just outside the exit of the CS, and P2 is resumed at the entry to the CS. P1 runs when P2 next stops.
OR!!!!
P2 remains suspended at the entry of the CS whilst P1 carries on from the end of the CS until it next stops. At that point, P2 enters the CS and does what it needs to do.

[gooddevil]

what about convoys?

[VirtualAce]

What exactly do you mean by 'critical section'? This could entail a lot of things.

The logical thing to do when a task terminates a a section of code that either has opened a file, allocated memory or resource, or has the highest priority on the queue would be to first de-allocate its resources. I'm assuming you mean this task has terminated pre-maturely either by hanging and the user ending the task or by faulty code. As long as you deallocate the resources that have been allocated by the task...then the OS should remain stable. Windows tracks all of this information very closely. It knows which semaphores belong to which tasks, and which tasks have allocated memory. Problems arise when 2 tasks share memory. De-allocating this memory would then result in the other task producing either a page fault -> if the memory is de-allocated and unlocked it can and probably will be paged to disk - accessing a page of memory that has been paged will produce a page fault. Also the second task might try to access memory that has been de-allocated by the system which would result in either another page fault since the memory no longer belongs to the task or if another task on the queue allocated the memory that had just been de-allocated...this would cause a general protection fault. Shared resources can cause a lot of problems and unfortunately that is what multi-tasking OS's frequently encounter.

There are a lot of things that can be done and a lot of design implementations for multi-tasking OS's. I've not completed my book on OS programming so I'm not familiar with much of it yet. Incidentally if they are using a TSS mechanism then the CPU itself can handle a lot of this burden - especially preserving CS, switching CS, etc. A TSS will save a lot of information about a task which lessens the load on an OS.

I have the DOS tech refs and from what I can tell DOS uses 2 stacks. But again I'm not positive about that one.

A virtual processor is a processor that emulates one CPU on an entirely different CPU. But you could also say that pretty much anything could be made into a virtual processor so I'm sort of lost on what you are getting at here. Below is a description of some threads....and I agree with Salem in that none of the things you listed seem to be virtual processors.

A thread is simply a task. Different OS's handle these differently so it depends on the design of the OS.

A kernel thread as I understand it would simply be a task on the queue that is essential to kernel operations. Note that all OSs do not have to use kernel threads...although the entire task switch queue mechanism and code could be considered its own thread. I'm sure that Windows allocated these threads differently and they have to have a higher priority...otherwise its possible that a lower priority task would be left doing nothing while the queue sat idly by in the background. I'm not positive that Windows does this but my design goal is to have 2 queues. One is for kernel processes and one is for user processes. In this way I know that no user process can adversely affect any kernel process.....theoretically.

Os theory is extremely complicated.

I've never heard of convoys.

[Russell]

> 4.what is a virtual processor?
I'd say none of the things you listed.
To my mind, its what the likes of VMWare (http://www.vmware.com/) give you

Isn't this HyperThreading?

[ZAK]

Kernel threads or processes are those processes in an operating system that can scheduled by the kernel of the operating system in other word the OS is completely aware they exist. You can think of a kernel thread as a whole new process in the operating system. User level threads get scheduled normally by a statically linked thread library (eg pthread). The kerenel of the OS is *not* aware of the threads it is only aware of the process the threads are contained in.
Hyper threading is a whole different beast. Hyper Threading allows the processor to do some of the process scheduling for the operating system but I do not believe it does all of the scheduling.