From owner-freebsd-threads@FreeBSD.ORG  Tue Dec 20 14:22:01 2011
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
Delivered-To: freebsd-threads@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A2C461065675;
	Tue, 20 Dec 2011 14:22:01 +0000 (UTC)
	(envelope-from phk@phk.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
	by mx1.freebsd.org (Postfix) with ESMTP id 5FEF28FC15;
	Tue, 20 Dec 2011 14:22:01 +0000 (UTC)
Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3])
	by phk.freebsd.dk (Postfix) with ESMTP id DE65D5E50;
	Tue, 20 Dec 2011 14:02:21 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBKE2LVd073234;
	Tue, 20 Dec 2011 14:02:21 GMT (envelope-from phk@phk.freebsd.dk)
To: John Baldwin <jhb@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Tue, 20 Dec 2011 08:22:25 EST."
	<201112200822.26369.jhb@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Date: Tue, 20 Dec 2011 14:02:21 +0000
Message-ID: <73233.1324389741@critter.freebsd.dk>
Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org
Subject: Re: [Patch] C1X threading support
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>, 
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2011 14:22:01 -0000

In message <201112200822.26369.jhb@freebsd.org>, John Baldwin writes:

>The reason I can think of why you might not specify 
>this is if you want to support machines that have very limited support for 
>atomic operations (e.g. only an exchange instruction or a single-bit test-and-
>set as opposed to a full-world test-and-set such as cmpxchg on x86 or cas on 
>sparc).

There is no way this can be impossible on a platform which can
implement a mutex in the first place:


	mtx_lock(l)
	{
		atomic_magic_lock(l->lock_field)
		l->id = thread_id;
	}

	mtx_unlock(l)
	{
		assert(l->id == thread_id);
		l->id = NULL;
		atomic_magic_unlock(l->lock_field)
	}

	mtx_assert_held(l)
	{
		assert(l->lock-field != 0);
		assert(l->id == thread_id);
	}


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.