Subj : Re: pthread_cond_signal() semantics To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Mon Jan 10 2005 11:37 am Giancarlo Niccolai writes: >> Ah, then ok, my implementation of threads for Kogut doesn't yield the >> processor on unlocking a mutex. >> > Mutexes in scripting languages are not "minimal" mutexes in any case: a > single VM loop is usually bigger than the minimal set of instructions you > want to lock with a pthread like mutex; so they anyhow follow different > rules. I don't have a VM loop, code is compiled into C. It does have various overheads compared to raw C code though (dynamic typing, passing function arguments through C global variables, almost all detectable errors are detected - programs can't crash, many higher order functions are used and they are not inlined). I don't use native threads; only one userspace thread is running at one time. When a function uses a stack frame (usually it means: when it contains some non-tail calls to other functions), it checks for stack overflow, and resizes the stack when needed. Thread preemption and Unix signal handling is implemented by faking the stack overflow condition, so there is no additional check for preemption in the fast path. Strictly speaking this is not portable: a signal handler may update a volatile variable of type sig_atomic_t but not a volatile pointer. But I think pointer updates are atomic wrt. signal handlers on all common architectures, so I don't make an alternative slower portable mechanism until it's actually needed. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .