RE: system call sched_yield() doesn't work on Linux 2.2

[Mohit Aron]

>	I'm using 2.4.1-pre10, glibc 2.1.3.

And I'm using Linux 2.2. And the sched_yield bug exists in Linux 2.2. I
found 
a huge number of posted bug reports on linux-kernel regarding this issue. 
Check http://boudicca.tux.org/hypermail/linux-kernel/2000week21/0858.html
for one.

> 	Thread1
> 	Thread1
> 	Thread1
> 	Thread1
> 	Thread1
> 	Thread2
> 	Thread2
> 	Thread2
> 	Thread2
> 	Thread2
>
>	That's totally reasonable, although you probably just forgot to
fflush.

Maybe to you. Not to anyone else who knows anything about systems. FYI,
stdout
is line buffered - so a printf ending in a "\n" is an automatic flush.

>	It's also possible Thread1 did all its work, yields and all, before
Thread2
> even got started. Thus Thread1 had no 'ready to run' thread to yield to.
> (The main thread may not have been ready to run, it may still have been
> waiting to synchronize to the new thread it created.)

What synchronization ? Even if thread1 started before main thread has a
chance to
create thread2, the first sched_yield would give main thread a chance to
create 
thread2. 

>	Find one pthreads expert who agrees with this claim. Post it to
> comp.programming.threads and let the guys who created the standard laugh
at
> you. Scheduling is not a substitute for synchronization, ever.

I for one am one. And I find your statement about laughable. Try posting
your
stuff on comp.programming.threads and see if you don't get the laughter that

you're expecting is lying in wait for me. Here is simple 
logic for you to figure out - if you have one run queue, and two threads
calling sched_yield() (and hence theoretically putting themselves at the end
of run queue), perfect alternation should be seen. Also, who's said I'm
trying to
synchronize based on scheduling - sched_yield() just isn't working, that's
all.

>	Your reasoning is totally invalid and ignores so many possible other
>factors. For example, who says that the writes that your threads are doing
> don't block?

If the printfs are blocking, then there's even more reason that the other
thread should run. And print its stuff. Put some pressure on your brain and
it might come to you.

>	I'm not sure I understand what this has to do with anything. If you
think
>so, then I don't think you appreciate with a standard actually is. Perfect
>alternation is reasonable, expecting perfect alternation is not. Probably
>the reason you got perfect alternation in Solaris is because you only had
>one kernel execution vehicle. Try it with system contention scope threads.

My Linux system is also idle. Even if one assumes that a sched_yield causes 
some other process to run on the CPU, the thread that caused sched_yield is
theoretically the last on the run queue. Hence no matter what other system
process is run first, the other thread should always run before the thread
that called sched_queue. Again my point of putting some pressure on your
brain ...

Also, I won't reply any further to anything you post. If you don't
understand
systems, kindly stay out of this discussion.

- Mohit