The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
Newsgroups: comp.os.ms-windows.programmer.win32, comp.programming.threads, microsoft.public.win32.programmer.kernel
From: Alexander Terekhov <terek...@web.de>
Date: Tue, 21 May 2002 12:54:28 +0200
Local: Tues, May 21 2002 6:54 am
Subject: Re: The implementation of condition variables in pthreads-win32
Joerg Faschingbauer wrote: "academic exercise" was the rationale! ;-) > >>>>> "Alexander" == Alexander Terekhov <terek...@web.de> writes: > Alexander> "Michael J. Saletnik" wrote: > Alexander> Could you please show us your impl (it is fairly simple > I wonder what was the rationale to do it the complicated way. Seriously, explicitly managed queue approach (like ZThreads's > I mean It depends, I guess. > the current pthreads-win32 condvar implementation is difficult to > grasp, and uses several OS objects for one condvar instance (where > "normal" Unix condvars usually do not need any kernel resources). > The Well, it could be done even w/o owning thread creation and > only reason I can think of is that you would be leaking the "blocker" > object (an event, I assume) when you don't own thread creation and > cleanup. cleanup -- just thread-specific events/semas (one would need "correctly working" cleanup of thread-specific data, though; that's somewhat a real challenge under brain-damaged win32- native--without-pthreads-win32-I-mean ;-)). > But when you are using pthreads-win32 you do own these. Well, the pthreads-win32 CV-impl. could be simplified quite > Or am I wrong? considerably... As another "academic exercise" it tries to fight (avoid generating of) spurious wakeups due to timeouts and cancel; That's absolutely NOT required by the POSIX Threads standard (*very wise decision*, given the presence of "application"-induced "spurious" wakeups; and the simplicity/ robustness of while or do "waiting" loops), and given that extra complexity and bookkeeping it takes to fight them (in the case of pthreads-win32, I mean), is just counter productive, I guess. ;-) regards, You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| ||||||||||||||