A few questions about Processes and Threads...

[EliteLegend]

Oh now I see... I always knew that my viewpoint that a programmer needs to take care of that will always lead me to trouble

As I keep advancing I'm getting some real dumb doubts... I don't understand the difference between User Semaphores and Kernel Semaphores... Do they differ only based on where they are implemented...? In that case, I was wondering if two threads of the same process could be synchroinzed using a kernel semaphore if the threads themselves are implemented by a kernel.. I feel that kernel threads should never need semaphores while if they are being implemented at the user level, they can be synchronized using kernel semaphores...

I'm a little confused now so if there was any mistake, kindly correct me....

[Avarok]

Heh...

I don't know what the difference is between a kernel thread and kernel semaphore and any other thread or semaphore.

My psuedo-code looks like this for context switches (it's actually written in asm, but I don't wanna scare the less inclined)

Code: Select all

do {
  calculate_where_to_store();
} while( first_one_through_cmpxchg_the_pointer() );

store();

do_stuff_to_maintain_queue();

do {
  calculate_where_to_load();
} while( first_one_through_cmpxchg_the_pointer() );

load();

What happens here is that any number of any kind of CPU gets to one of these do/while loop thingers. If the value changes while you're doing your math, you try again. If another CPU gets interrupted while in this section, it won't interfere.

I can use shared dynamically allocated arrays and only lock 1 pointer cmpxchg this way - because you don't need to lock the move - just need to lock the allocation of space for it (advancement of the pointer).

What are the disadvantages you can see to this strategy vs semaphores or mutexes?

[JamesM]

I don't know what the difference is between a kernel thread and kernel semaphore and any other thread or semaphore.

A kernel thread is a thread which the kernel knows about. That is, it can schedule that thread to run if it wants to.

The kernel knows nothing about user threads. A user-space library usually uses alarm() calls to effect a signal, where it manually saves the current context and switches thread. The difference between these is what the kernel knows and where the switching takes place.

What that means is that if you have 2 kernel threads, A & B, and thread A is sleeping/blocked, thread B can be run.

If you have 2 user threads, A and B, the kernel only knows about one of them (whichever is currently active), so if it (thread A) is sleeping/blocked, thread B cannot be scheduled.

And yet, kernel threads (historically) take more overhead to set up and use.