On 03 Jun 2003 11:12:43 +0300
Gilboa Davara <[EMAIL PROTECTED]> wrote:
> B. Events (posix conditions).
> Wait it doesn't work right (PulseEvent never did... MS, like MS, just
> refuses to fix it), NT events are much easier to use, and have much
> better control. The posix conditions are a just pain in the back side.
Posix conditions and mutexes are two low level mechanisms that complement
each other (that's why you need a mutex to manipulate a condition variable.
It is trivial to use these two *low level* abstractions to create a
higher level constructs like a counting semaphore (on which you
can easily wait). Can you fill the following API (I can mail you the
implementation if you really need it):
#ifndef COUNTING_SEM_H
#define COUNTING_SEM_H
#include <pthread.h>
class CountingSem {
public:
CountingSem(int start_value);
void inc();
void dec();
private:
pthread_mutex_t lock; /* atomic access to value */
pthread_cond_t wait; /* lock block on CV */
int value; /* This is semaphre value */
};
#endif /* COUNTING_SEM_H */
> E. Wait functions.
> WaitForSingleObject (WaitForMulitpleObjects) is by far better then
> anything posix. The ability to create a single wait that will work on
> threads, processes, files, events, mutexes, etc, is a true blessing.
> I'm currently looking into ways to emulate the WaitFor* on posix
> machines.
I completely agree that not representing these constructs as common
Unix file descriptors (just like SysV IPC isn't represented the same)
force one to handle each case separately. This is obviously a design
bug.
However, you should remember that due to the genious fork() design
(discussed by Shachar in other post), many Unix apps doesn't have to deal
with the complexities in the threaded model. Unix programmers used
paralelism for ~20 years without threads. Threads entered to the Unix world
at the begining of the 90's (because for *some* tasks threads *are* the
easiest paralelism method).
Regretfully, many programmers coming from the Win* school equate:
parallel execution == multi-threaded
Even when this design leads to complexity and bloat typical of windows:
One big process handling every possible task
Instead of adopting the easier Unix paradigm (when appropriate):
Many small processes each doing one thing well
--
Oron Peled Voice/Fax: +972-4-8228492
[EMAIL PROTECTED] http://www.actcom.co.il/~oron
"There are lies, damned lies, and statistics" -- Benjamin Disraeli
"...and benchmarks" -- Garry Hodgson
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
