C is fixed or not ?

[MikeP]

I don't get on here as often as a I used to


my name isn't Joe

Thx. I cracked up when I read that. :]

 

[MikeP]

no. I meant exactly what I said. I find it odd that people scorn
theory. It's our guide to the world.

Sowwy, I didn't know I was in church.

you missed my point. If Unix can be programmed in C because it was
implemented in C (a dumb argument in the first place) why shouldn't
Windows be oprogrammed in C?

Because it is obsolete\

slash = question mark, I'm not going to fight it.

so enlighten us. Is it all going to be programmed in .Net?

Are their 2 questions there\

 

[Ben Bacarisse]

Or maybe you should get the **** out of my face?

Happy to oblige.

<snip>

 

[BGB]

CAN be. If you name them, THEN they can be used amongst processes.
Unnamed synch objects are intra-process. Whether having unnamed synch
objects makes them lighter-weight (higher performance) in usage, I don't
know. Simple enough to profile though.

these mutexes are very expensive, almost absurdly slow. a lock/unlock
cycle takes around 1-2us, which is far longer than most operations one
may reasonably want to lock (on a reasonably modern computer, this is
around 3000 to 6000 clock cycles).

"Critical Sections" are a bit faster, and so are preferable to the
generic mutex objects (but, much faster than dead slow is still not
necessarily fast).


much faster IME was to implement a spinlock-with-sleeep operation (using
"InterlockedExchange", ...), which can generally handle
locking/unlocking in the low ns range (more around 5ns or so).

the above fast mutexes make a lot more sense when ones' goal is
something like:
lock mutex;
add entry to cross-thread linked list (such as a message queue);
unlock mutex.

or: the corresponding action to remove something from a linked-list.


rather than... whatever the hell MS intends their mutexes for...