That is most odd. Could you try to minimize the differences between your version and mine to see when it stops working? Can't do it myself since my variant works for me (it's exactly that fix I've made in a couple of places in the WebServer 3.3 cvs). It must some strange compiler bug here.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-10-24 21:21: Subject: pike 7.3 Thread.Condition.wait and roxen.pike
It works. At least for me, which yours doesn't.
/ Martin Nilsson (Fake Build Master)
This works:
object mutex = Thread.Mutex(); Thread.Condition()->wait(mutex->lock());
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-25 02:11: Subject: pike 7.3 Thread.Condition.wait and roxen.pike
That is most odd. Could you try to minimize the differences between your version and mine to see when it stops working? Can't do it myself since my variant works for me (it's exactly that fix I've made in a couple of places in the WebServer 3.3 cvs). It must some strange compiler bug here.
/ Martin Stjernholm, Roxen IS
In a minimized test case? I.e. this
int main() { object mutex = Thread.Mutex(); Thread.Condition()->wait(mutex->lock()); }
works while this
int main() { Thread.Condition()->wait(Thread.Mutex()->lock()); }
doesn't work for you?
/ Martin Stjernholm, Roxen IS
Previous text:
2002-10-25 12:44: Subject: pike 7.3 Thread.Condition.wait and roxen.pike
This works:
object mutex = Thread.Mutex(); Thread.Condition()->wait(mutex->lock());
/ Martin Nilsson (Fake Build Master)
That's right.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-25 16:44: Subject: pike 7.3 Thread.Condition.wait and roxen.pike
In a minimized test case? I.e. this
int main() { object mutex = Thread.Mutex(); Thread.Condition()->wait(mutex->lock()); }
works while this
int main() { Thread.Condition()->wait(Thread.Mutex()->lock()); }
doesn't work for you?
/ Martin Stjernholm, Roxen IS
It turned out to be caused by the mutex lock object that doesn't hold a reference to the mutex, and the lock is destructed when the mutex is refcount garbed before the call to wait(). (I still don't know what difference is causing the destruct to consistently be sufficiently delayed for me but not for Nilsson.)
Anyway, what is the reason behind the design that MutexKeys doesn't reference their Mutexes? It could potentially cause problems in more relevant cases than this, e.g. during a shutdown sequence if the object containing the mutex is gc'd while there still are several threads that is waiting to get a lock.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-10-25 16:44: Subject: pike 7.3 Thread.Condition.wait and roxen.pike
In a minimized test case? I.e. this
int main() { object mutex = Thread.Mutex(); Thread.Condition()->wait(mutex->lock()); }
works while this
int main() { Thread.Condition()->wait(Thread.Mutex()->lock()); }
doesn't work for you?
/ Martin Stjernholm, Roxen IS
Sounds broken to me. Has it always been that way?
BTW, what happens if I explicitly destroy a mutex, which is locked?
/ Niels Möller ()
Previous text:
2002-10-27 15:15: Subject: References to Thread.Mutex
It turned out to be caused by the mutex lock object that doesn't hold a reference to the mutex, and the lock is destructed when the mutex is refcount garbed before the call to wait(). (I still don't know what difference is causing the destruct to consistently be sufficiently delayed for me but not for Nilsson.)
Anyway, what is the reason behind the design that MutexKeys doesn't reference their Mutexes? It could potentially cause problems in more relevant cases than this, e.g. during a shutdown sequence if the object containing the mutex is gc'd while there still are several threads that is waiting to get a lock.
/ Martin Stjernholm, Roxen IS
As far as I know, yes. It doesn't really look intentional, which I thought first when I read the doc.
BTW, what happens if I explicitly destroy a mutex, which is locked?
The lock is released and destructed.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-10-27 22:22: Subject: References to Thread.Mutex
Sounds broken to me. Has it always been that way?
BTW, what happens if I explicitly destroy a mutex, which is locked?
/ Niels Möller ()
You can't try to lock a mutex without having a reference to it. (Since calling mutex->lock will retain a reference in the frame pointer)
I don't remember if there any reasons for why keys don't reference their mutex, except to facilitate garbage collection. It is however vitally important that mutexes do not have references to the keys, and once I had figured out how to do that I probably just applied that symmetrically.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2002-10-27 15:15: Subject: References to Thread.Mutex
It turned out to be caused by the mutex lock object that doesn't hold a reference to the mutex, and the lock is destructed when the mutex is refcount garbed before the call to wait(). (I still don't know what difference is causing the destruct to consistently be sufficiently delayed for me but not for Nilsson.)
Anyway, what is the reason behind the design that MutexKeys doesn't reference their Mutexes? It could potentially cause problems in more relevant cases than this, e.g. during a shutdown sequence if the object containing the mutex is gc'd while there still are several threads that is waiting to get a lock.
/ Martin Stjernholm, Roxen IS
You're right. But something else I think could happen before my reference fix was that a mutex could loose all its references while inside a cond->wait(mutex_key), thereby destructing the key that should be locked again on exit.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-10-31 21:20: Subject: References to Thread.Mutex
You can't try to lock a mutex without having a reference to it. (Since calling mutex->lock will retain a reference in the frame pointer)
I don't remember if there any reasons for why keys don't reference their mutex, except to facilitate garbage collection. It is however vitally important that mutexes do not have references to the keys, and once I had figured out how to do that I probably just applied that symmetrically.
/ Fredrik (Naranek) Hubinette (Real Build Master)
You're right. But something else I think could happen before my reference fix was that a mutex could loose all its references while inside a cond->wait(mutex_key), thereby destructing the key that should be locked again on exit.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-10-31 21:20: Subject: References to Thread.Mutex
You can't try to lock a mutex without having a reference to it. (Since calling mutex->lock will retain a reference in the frame pointer)
I don't remember if there any reasons for why keys don't reference their mutex, except to facilitate garbage collection. It is however vitally important that mutexes do not have references to the keys, and once I had figured out how to do that I probably just applied that symmetrically.
/ Fredrik (Naranek) Hubinette (Real Build Master)
You're right. But something else I think could happen before my reference fix was that a mutex could loose all its references while inside a cond->wait(mutex_key), thereby destructing the key that should be locked again on exit.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-10-31 21:20: Subject: References to Thread.Mutex
You can't try to lock a mutex without having a reference to it. (Since calling mutex->lock will retain a reference in the frame pointer)
I don't remember if there any reasons for why keys don't reference their mutex, except to facilitate garbage collection. It is however vitally important that mutexes do not have references to the keys, and once I had figured out how to do that I probably just applied that symmetrically.
/ Fredrik (Naranek) Hubinette (Real Build Master)
You can't try to lock a mutex without having a reference to it. (Since calling mutex->lock will retain a reference in the frame pointer)
I don't remember if there any reasons for why keys don't reference their mutex, except to facilitate garbage collection. It is however vitally important that mutexes do not have references to the keys, and once I had figured out how to do that I probably just applied that symmetrically.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2002-10-27 15:15: Subject: References to Thread.Mutex
It turned out to be caused by the mutex lock object that doesn't hold a reference to the mutex, and the lock is destructed when the mutex is refcount garbed before the call to wait(). (I still don't know what difference is causing the destruct to consistently be sufficiently delayed for me but not for Nilsson.)
Anyway, what is the reason behind the design that MutexKeys doesn't reference their Mutexes? It could potentially cause problems in more relevant cases than this, e.g. during a shutdown sequence if the object containing the mutex is gc'd while there still are several threads that is waiting to get a lock.
/ Martin Stjernholm, Roxen IS
You can't try to lock a mutex without having a reference to it. (Since calling mutex->lock will retain a reference in the frame pointer)
I don't remember if there any reasons for why keys don't reference their mutex, except to facilitate garbage collection. It is however vitally important that mutexes do not have references to the keys, and once I had figured out how to do that I probably just applied that symmetrically.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2002-10-27 15:15: Subject: References to Thread.Mutex
It turned out to be caused by the mutex lock object that doesn't hold a reference to the mutex, and the lock is destructed when the mutex is refcount garbed before the call to wait(). (I still don't know what difference is causing the destruct to consistently be sufficiently delayed for me but not for Nilsson.)
Anyway, what is the reason behind the design that MutexKeys doesn't reference their Mutexes? It could potentially cause problems in more relevant cases than this, e.g. during a shutdown sequence if the object containing the mutex is gc'd while there still are several threads that is waiting to get a lock.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se
-
Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum -
Martin Nilsson (Fake Build Master) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Niels M�ller () ＠ Pike (-) developers forum