Stephen R. van den Berg wrote:
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
Lots of code depends on the interpreter lock. With something as core as Concurrent we really need both correctness and performance. First step would be to write good performance benchmarks though.
Ok. I'll run through it once more and optimise.
I ran some tests on Pike 8.0 and 8.1 using the following program:
--------------------cut here----------------- Thread.Mutex mux = Thread.Mutex(); int c = 1;
class des { string label; void create(string lab) { label = lab; werror("Created! %s ******************\n", label); } void destroy() { werror("Destroyed! %s ***************\n", label); } }
void a(int ... v) { werror("a...\n"); des y = des("yy"); { des x = des("xx"); Thread.MutexKey lock = mux->lock(); werror("a got lock\n"); sleep(0.5); c++; //sleep(0.000001); } //sleep(0.000001); c++; werror("a out of sleep\n"); c++; sleep(0.5); c++; werror("a unlocked\n"); c++; }
void b(int ... v) { werror("b...\n"); Thread.MutexKey lock = mux->lock(); werror("b got lock %d\n", c); sleep(1); werror("b out of sleep\n"); lock = 0; werror("b unlocked\n"); }
int main(int argc, array(string) argv) { Thread.Thread(a); sleep(0.2); Thread.Thread(b); sleep(2); return 0; } --------------------cut here-----------------
When running it (repeatedly), I notice the following things: a. To my delight I see that object destructors are consistently being run at the closing brace of a block. Cheers! (Makes me wonder when this changed, because in 7.8 it did not work this way yet, I think). b. The moment when it switches to thread b varies, depending on chance/timing. c. Sometimes at switch time c is either 2, or 3, or 4. Which is fine. d. Note that despite one would expect 2 to be impossible due to the interpreter lock, it is possible because running the destructors at the end of that block probably breaks that promise.
So it appears that I can reliably get rid of some of the MutexKey = 0 assignments. And, I'll start relying on the interpreter lock for the trivial cases (pointer and immediate use of that pointer). In addition, I'll scrutinise the hotspot places of mutexes to see if we can get by without a mutex if the interpreter lock can trivially be utilised.