From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751622AbbKHKgB (ORCPT <rfc822;w@1wt.eu>);
	Sun, 8 Nov 2015 05:36:01 -0500
Received: from mout.kundenserver.de ([212.227.17.24]:60908 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750788AbbKHKf5 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 8 Nov 2015 05:35:57 -0500
From: Arnd Bergmann <arnd@arndb.de>
To: Octavian Purdila <octavian.purdila@intel.com>
Cc: Linux-Arch <linux-arch@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Hajime Tazaki <thehajime@gmail.com>
Subject: Re: [RFC PATCH 21/28] lkl tools: host lib: posix host operations
Date: Sun, 08 Nov 2015 11:35:46 +0100
Message-ID: <3793143.1m2WrnCXBd@wuerfel>
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <CAE1zotLiR_4KdPtVr8MANb2kKVhUZKzCCaUdEV=0cBTfkV2KQw@mail.gmail.com>
References: <1446582059-17355-1-git-send-email-octavian.purdila@intel.com> <42449799.QsmXDGnQ4P@wuerfel> <CAE1zotLiR_4KdPtVr8MANb2kKVhUZKzCCaUdEV=0cBTfkV2KQw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:93UtaiEXPlP/zIbJinl3erWkHL4f8uKjTSRqrgikPB2mA7TVIo6
 osNTjsHWfVVEkYgFUK2BP2TtOHLMtFxqJNEeldJamt4mKwzr7HhGycPdGyWI8h+pPnQNeSC
 RAdfhbYhdQtAn8mYmmDd37iUCSBL/vO/T3jYkjzhS6jQX1nj9pKNQKJJw+zzwBt8qQuy/R9
 PuEK+Zj6uCRoZhaev4V4w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:VqTg5+gJT5A=:XXpzOtQ0cSg/TO73+oyY+W
 L36AD40cNv1SW2AHWGwoPX9gu5zthyrpUk7cOjp82/LrYFkMUX4ohzYRbPJaQSzXb7hxvy8f3
 OR7ntn9+xoY8ibpXGmzj5+teF2NC1hB6Ucr6Ov+zcOBfLBsDR1qkCxRtYgpOTcgT/T/vxhhq4
 rw6dyJfpzb7MJcDcBa0O6WoLZ0T0CAEXcLDQofbLIdPVw2brQwy0DMgHbiEalJagt55mw6GJX
 yr4toN/u9GqRjDuyXKQVWNEiNpXHXNqiW65fK9GbpELLPYSsEVmhQcGcuBKu8EHsLeBvV/HqA
 3tp/toh1ILnj18lZOAjp5TcqX4IdOSk79RwRsLRIPbzfJ3/VTTqk2D6JSmg55zMewsmWoEEQV
 0i8I/15+cnMBtonyWmrsIESA9FzakRzu+NHdJITuu76JXt8Rs0ftpn1Bk+6LcXiVDwHMuUNMS
 OIu1qJd4mLIt94PMEqhKAS4qjjgVevKs+CngaLximVUG6EXGHEGFk2GJitnuWWlzT8l1k06TX
 y5Wb4pMMhrHinM0JImDM0uHvv+wa/bsQ/rw1kUmPSMohwXn/HN1Cd1vmAMxu4trrFBBdSC7c7
 OdeH5kATsDCCQZQBxhrlGjeha4Q6swoaHAcWqmQdKWsGDNeLLX87lwmmgDd3tGxyZG/+VyXeG
 iMRvVRFGEmhXw8JWg7dyg27SAizDU469DoEuOeJdxqF6nYy2NkNzahmIBUdgvJD5IlkQq7Nwx
 O7279dtMjaWzrSBR
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sunday 08 November 2015 06:01:08 Octavian Purdila wrote:
> >> +static void *sem_alloc(int count)
> >> +{
> >> +     struct pthread_sem *sem;
> >> +
> >> +     sem = malloc(sizeof(*sem));
> >> +     if (!sem)
> >> +             return NULL;
> >> +
> >> +     pthread_mutex_init(&sem->lock, NULL);
> >> +     sem->count = count;
> >> +     pthread_cond_init(&sem->cond, NULL);
> >> +
> >> +     return sem;
> >> +}
> >
> > What is the reason to have generalized semaphores in the
> > host API rather than a simple mutex?
> >
> 
> Currently waking up from idle after an IRQ event requires a semaphore.
> I'll see if we can use a simple mutex for this.

According to the pthread_mutex_unlock() man page, you are not allowed
to unlock a mutex from any thread other than the one that owns the
mutex through pthread_mutex_lock(), so if the IRQ event is sent to
another thread, that would not be safe even if it happens to work
on linux+glibc.

Another option would be to use futexes as the basic primitive, which
might make the implementation for Linux hosts a bit more efficient,
but complicates the implementation for hosts that do not implement
those.

	Arnd