teunis wrote:
> mutex locking time is... *heh* around 26000 microseconds... Longer than
> poll().... Go figure.
So much ? Well, it must be implemented via a system call then...
Well, with threads managed by the kernel it is not so astonishing,
but you can surely do much better if you only want to lock
in-memory data structures...
Which library do you use for threads/mutexes, linuxthread ? POSIX ?
Oh. by the way, while I'm thinking, how did you do your benchmark ?
An empty lock/unlock I guess ? Not by two threads on a uniprocessor
I hope (this environment implies a scheduling so... here is your
implicit system call....)
Well, anyway, I'd be interested in seing your benchmark
if it's a simple test programs. So much time for locking
seems astounding to me.
(With Chorus on a 386 in 1994, it was much faster...)
> Now on the flip side, it'd be very handy to have a libGGIthreads library
> or something to give one a threaded interface to -all- of GGI.
Hmmm. With additional delays, I don't know if it would be worth
the work (especially as everyone would try to use for hype and then
go back complaining about the performance)...
Nevertheless, your application is very interesting with
respect to this issue of real-graphic-world MT programming !
Rodolphe
