In article <[EMAIL PROTECTED]>, Sergei Organov <[EMAIL PROTECTED]> writes: |> |> OK, then I don't think the POSIX threads were "perpetrated" to be idle |> most of time.
Perhaps I was being unclear. I should have added "In the case where there are more threads per system than CPUs per system". The reasons are extremely obscure and are to do with the scheduling, memory access and communication. I am in full agreement that the above effect was not INTENDED. |> > That is why many POSIX threads programs work until the genuinely |> > shared memory accesses become frequent enough that you get some to the |> > same location in a single machine cycle. |> |> Sorry, I don't understand. Are you saying that it's inherently |> impossible to write an application that uses POSIX threads and that |> doesn't have bugs accessing shared state? I thought that pthreads |> mutexes guarantee sequential access to shared data. Or do you mean |> something entirely different? Lock-free algorithms maybe? I mean precisely the first. The C99 standard uses a bizarre consistency model, which requires serial execution, and its consistency is defined in terms of only volatile objects and external I/O. Any form of memory access, signalling or whatever is outside that, and is undefined behaviour. POSIX uses a different but equally bizarre one, based on some function calls being "thread-safe" and others forcing "consistency" (which is not actually defined, and there are many possible, incompatible, interpretations). It leaves all language aspects (including allowed code movement) to C. There are no concepts in common between C's and POSIX's consistency specifications (even when they are precise enough to use), and so no way of mapping the two standards together. Regards, Nick Maclaren. -- http://mail.python.org/mailman/listinfo/python-list
