[M3devel] up-front initialization of mutex/conditionvariable?

[Tony Hosking]

Yes, good point.  It really is a question of how much does the safe-point check cost.  Perhaps for a "systems" language like Modula-3 it is important that we not tax code that doesn't use threads or locks.  But in today's world code like that is less common, no?  And Modula-3 positively encourages them.  On the other hand, Modula-3 demands programmers explicitly declare their locks (unlike Java which says any object can be a lock or CV), so perhaps retaining the referential transparency of explicit locks (you don't pay unless you use them) is more in the Modula-3 "systems" programming way of thinking.

There are other ways to do the safe-points. One could "poison" (access-protect) a page that the thread simply reads a location from at the safe-points, whereupon it will trap.

But in some experiments we have done with Java, it is more important that the thread simply ack, rather than having actually to take a trap and come to a screeching halt in a signal handler.  And, since most threads are usually blocked or executing some external system call, you don't even have to wait for the ack.

On 15 Dec 2009, at 09:08, hendrik at topoi.pooq.com wrote:

> On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote:
>> So, the basic scenario is as follows.  Briefly... We should ditch 
>> signals as a mechanism for stopping threads.  The compiler should 
>> inject a "safe-point" at each procedure call and backward branch.  At 
>> safe-points, the thread polls a thread-local to see if the run-time 
>> system needs it to step out-of-line for some reason.
> 
> ...
> ...
>> 
>> The point is that uncontended locks should cost almost nothing.
> 
> Nothing?  All those safe-points cost time, don't they, even when no 
> locks are being used at all?
> 
> Is this analogous to charging everyone for the overhead involved in 
> recursion, even when no recursion is being used?
> 
> -- hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091215/24431613/attachment-0002.html>