From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 52F397EE4B for ; Mon, 30 Sep 2013 18:01:19 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 176.9.138.55 as permitted sender) identity=mailfrom; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@mail.etorok.net designates 176.9.138.55 as permitted sender) identity=helo; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFqfSVKwCYo3/2dsb2JhbABagwc4wU+BLRZ0giUBAQVAAQE2Ag8LGAkWDwkDAgECAUUTBgICiAaqUIRQAQWOSgaOEhCBNhaEDIk2jkyGM4tGgyeBZQ X-IPAS-Result: AgIFAFqfSVKwCYo3/2dsb2JhbABagwc4wU+BLRZ0giUBAQVAAQE2Ag8LGAkWDwkDAgECAUUTBgICiAaqUIRQAQWOSgaOEhCBNhaEDIk2jkyGM4tGgyeBZQ X-IronPort-AV: E=Sophos;i="4.90,1008,1371074400"; d="scan'208";a="34946111" Received: from mail.etorok.net ([176.9.138.55]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Sep 2013 18:01:15 +0200 Received: from [172.30.42.25] (unknown [79.114.31.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.etorok.net (Postfix) with ESMTPSA id DFF9D46D8 for ; Mon, 30 Sep 2013 18:01:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=etorok.net; s=mailout; t=1380556874; bh=AzPdqkdKGmH7mNlRKhIeeQPoliBuOGUfr5ZF/DADOF8=; l=2486; h=Date:From:To:References:In-Reply-To:From; b=Y8XFaFBOzYsZXOnuvWFghjtrU4wUSL+/iGJ0pPIhKV+Hkt1OwQ848twZVfvudd3Ue 2obWkB/i3ss2e0gydNUXWBcimcX8i3H7KW4sgcZOK2P84zBgTQGKJ9kc167iurDS01 0POnEvzszFjTbHRtQmCJylmC8Sn7DA3O5331Wj2w= Message-ID: <5249A04A.4010800@etorok.net> Date: Mon, 30 Sep 2013 19:01:14 +0300 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130929 Icedove/17.0.9 MIME-Version: 1.0 To: caml-list@inria.fr References: <524941CC.1080906@inria.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [Caml-list] Thread behaviour On 09/30/2013 06:12 PM, Tom Ridge wrote: > On 30 September 2013 10:18, Xavier Leroy wrote: >> On 2013-09-27 12:10, Tom Ridge wrote: >>> I have a little program which creates a thread, and then sits in a loop: >>> [...] >>> When I run the program I get the output: >>> >>> 1 >>> 2 >>> >>> and the program then sits in the loop. >> >> On my machine (OCaml 4.01.0, Ubuntu 12.04 LTS), I sometimes see what >> you see, and sometimes I see the expected output: >> >> 1 >> 2 >> 3 >> hello >> 4 >> >> It all depends on the whim of the OS scheduler. OCaml has no control >> over it. And you shoudn't expect any kind of fairness from the OS >> scheduler, esp. Linux's, which gladly jettisons any pretense of >> fairness in the hope of getting better throughput. >> > > Ah! You are saying that the problem (maybe) lies with the Linux scheduler. > This had never occurred to me. Probably because I assumed the Linux > phrase "completely fair scheduler" meant something (although > admittedly, I never tried to find out what). I think there are two things to consider here: * deciding which process(es) to run on the CPU(s), when there are multiple runnable processes/threads (i.e. they are not blocked/sleeping). This is called CFS in Linux, and you can check how well it behaves with top %CPU, /proc/sched_debug, etc. Although it has some heuristics too, for example related to pipe(2) handling. * deciding how to lock a mutex / what thread to wake up when a mutex is released/ condvar is signaled This is handled first in libpthread (IIRC there is some limited user-space spinning involved), then handed off to the kernel via futex(7). Depending how its implemented there can be fairness issues, see also 'thundering herd' problem, etc. AFAIK the kernel uses ticket locks for its spinlocks to get more fairness since quite some time (see http://lwn.net/Articles/267968/ and http://lwn.net/Articles/531254/), but I lost track whether futexes actually use this mechanism or something else. If there is something wrong with the fairness in thread scheduling I'd expect it to be in this part though. As far as OCaml is concerned one might try to implement something similar to ticket locks in userspace (or have an array of condition variables and wake up directly the thread we want, and track their execution times?), but it won't be as efficient as if the kernel was (fixed) to do it properly. Best regards, --Edwin