Mutex: Difference between revisions

{{requires|Concurrency}}

[[Category:Encyclopedia]]

 

A mutex is said to be seized by a [[task]] decreasing ''k''.

It is released when the task restores ''k''. Mutexes are typically used to protect a shared resource from concurrent access.

 

=Sample implementations / APIs=

 

=={{header|Ada}}==

 

The mutex interface:

entry Seize;

procedure Release;

private

Owned : Boolean := False;

The implementation of:

entry Seize when not Owned is

begin

Owned := False;

end Release;

Here the entry Seize has a queue of the [[task]]s waiting for the mutex. The entry's barrier is closed when Owned is true. So any task calling to the entry will be queued. When the barrier is open the first task from the queue executes the entry and Owned becomes true closing the barrier again. The procedure Release simply sets Owned to false. Both Seize and Release are protected actions whose execution causes reevaluation of all barriers, in this case one of Seize.

 

Use:

M : Mutex;

begin

... -- Critical code

M.Release; -- Release the mutex

It is also possible to implement mutex as a monitor task.

=={{header|BBC BASIC}}==

{{works with|BBC BASIC for Windows}}

SYS "CreateMutex", 0, 0, 0 TO hMutex%

REM Free mutex:

 

=={{header|C}}==

{{works with|Win32}}

To create a mutex operating system "object":

To lock the mutex:

To unlock the mutex

When the program is finished with the mutex:

 

===POSIX===

Creating a mutex:

 

 

 

Or:

 

 

Locking:

 

 

Unlocking:

 

 

Trying to lock (but do not wait if it can't)

 

 

=={{header|C++}}==

 

=={{header|D}}==

class Synced

{

static num = 0;

}

 

Keep in mind that '''synchronized''' used as above works on a per-class-instance basis.

 

The following example tries to illustrate the problem:

 

class Synced {

tested.func(d_id);

}

 

Every created thread creates its own '''Synced''' object, and because the monitor created by synchronized statement is created for every object,

like here:

 

class Synced {

public int func (int input) {

private static int foo;

}

 

=={{header|E}}==

E's approach to concurrency is to ''never'' block, in favor of message passing/event queues/callbacks. Therefore, it is unidiomatic to use a mutex at all, and incorrect, or rather ''unsafe'', to use a mutex which blocks the calling thread. That said, here is a mutex written in E.

 

 

# The mutex is available (released) if available is resolved, otherwise it

}

return mutex

 

This implementation of a mutex is designed to have a very short implementation as well as usage in E. The mutex object is a function which takes a function ''action'' to be executed once the mutex is available. The mutex is unavailable until the return value of ''action'' resolves. This interface has been chosen over lock and unlock operations to reduce the hazard of unbalanced lock/unlock pairs, and because it naturally fits into E code.

Usage example:

 

 

? def mutex := makeMutex()

 

? value

 

<code>when</code> blocks and <code>Ref.whenResolved</code> return a ''promise'' for the result of the deferred action, so the mutex here waits for the gratuitously complicated increment to complete before becoming available for the next action.

=={{header|Erlang}}==

Erlang has no mutexes so this is a super simple one, hand built to allow 3 slowly printing processes to print until done before the next one starts.

-module( mutex ).

 

 

task() ->

 

 

 

loop() ->

 

mutex_acquire( Pid ) ->

 

mutex_release( Pid ) -> Pid ! {release, erlang:self()}.

print( _Mutex, _N, 0 ) -> ok;

print( Mutex, N, M ) ->

 

print_slow( X ) ->

{{out}}

<pre>

Print 3: 1 2 3

</pre>

 

=={{header|Go}}==

{{trans|E}}

Go has mutexes, and here is an example use of a mutex, somewhat following the example of E. This code defines a slow incrementer, that reads a variable, then a significant amount of time later, writes an incremented value back to the variable. Two incrementers are started concurrently. Without the mutex, one would overwrite the other and the result would be 1. Using a mutex, as shown here, one waits for the other and the result is 2.

 

import (

wg.Wait()

fmt.Println(value)

{{out}}

<pre>

As soon as things start getting complicated though, Go channels offer a much clearer alternative.

As a gateway from mutexes to channels, here is the above program implemented with channels:

 

import (

<-done

fmt.Println(value)

The value passed on the channel is not accessed here, just as the internal state of a mutex is not accessed. Rather, it is only the effect of the value being available that is important. (Of course if you wanted to send something meaningful on the channel, a reference to the shared resource would be a good start...)

 

Haskell has a slight variation on the mutex, namely the MVar. MVars, unlike mutexes, are containers. However, they are similar enough that MVar () is essentially a mutex. A MVar can be in two states: empty or full, only storing a value when full. There are 4 main ways to deal with MVars:

 

putMVar :: MVar a -> a -> IO ()

tryTakeMVar :: MVar a -> IO (Maybe a)

tryPutMVar :: MVar a -> a -> IO Bool

 

takeMVar will attempt to fetch a value from the MVar, and will block while the MVar is empty. After using this, the MVar will be left empty.

The following code uses features exclusive to Unicon.

 

 

x: = mutex() # create and return a mutex handle for sharing between threads needing to synchronize with each other

unlock(x) # unlock mutex x

 

=={{header|Java}}==

{{works with|Java|1.5+}}

 

Java 5 added a <code>Semaphore</code> class which can act as a mutex (as stated above, a mutex is "a variant of semaphore with ''k''=1").

 

public class VolatileClass{

}

//delegate methods could be added for acquiring and releasing the mutex

Using the mutex:

public static void main(String[] args){

VolatileClass vc = new VolatileClass();

vc.mutex.release();

}

 

Java also has the synchronized keyword, which allows almost any object to be used to enforce mutual exclusion.

 

static Object mutex = new Object();

static int i = 0;

}.start();

}

 

The "synchronized" keyword actually is a form of [[monitor]], which was a later-proposed solution to the same problems that mutexes and semaphores were designed to solve. More about synchronization may be found on Sun's website - http://java.sun.com/docs/books/tutorial/essential/concurrency/sync.html , and more about monitors may be found in any decent operating systems textbook.

 

=={{header|Logtalk}}==

Logtalk provides a synchronized/0 directive for synchronizing all object (or category) predicates using the same implicit mutex and a synchronized/1 directive for synchronizing a set of predicates using the same implicit mutex. Follow an usage example of the synchronized/1 directive (inspired by the Erlang example). Works when using SWI-Prolog, XSB, or YAP as the backend compiler.

:- object(slow_print).

 

 

:- end_object.

{{out}}

<pre>

 

=={{header|M2000 Interpreter}}==

Module CheckIt {

Thread.Plan Concurrent

\\ we use N$, C and Max as stack variables for each thread

\\ all other variables are shared for module

C++

if c=1 then thread this interval 20

} as K

Read M$

Thread K interval Random(300, 2000)

}

Service=m.lock()

Main.Task 50 {

If Service Then if Keypress(32) then m.unlock: Service=false: Continue

If not Service then if Keypress(32) Then if m.lock() then Service=true : Continue

if PhoneBooth.NowUser$<>"" Then {

}

}

CheckIt

 

=={{header|Nim}}==

 

Creating a mutex:

 

Locking:

Unlocking:

# Trying to lock (but do not wait if it can't)

 

=={{header|Objective-C}}==

 

 

[m lock]; // locks in blocking mode

}

 

Reentrant mutex is provided by the <tt>NSRecursiveLock</tt> class.

 

Objective-C also has [http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocThreading.html#//apple_ref/doc/uid/TP30001163-CH19-BCIIGGHG @synchronized() blocks], like Java.

 

=={{header|OCaml}}==

It is very simple, there are four functions:

 

Mutex.lock m; (* locks in blocking mode *)

 

else ... (* already locked, do not block *)

 

=={{header|Oforth}}==

If the channel is empty, a task will wait until an object is available into the channel.

 

 

: job(mut)

| mut |

Channel new dup send(1) drop ->mut

 

=={{header|Oz}}==

 

Creating a mutex:

 

The only way to acquire a mutex is to use the <code>lock</code> syntax. This ensures that releasing a lock can never be forgotten. Even if an exception occurs, the lock will be released.

{System.show exclusive}

 

To make it easier to work with objects, classes can be marked with the property <code>locking</code>. Instances of such classes have their own internal lock and can use a variant of the <code>lock</code> syntax:

prop locking

 

meth test

lock

end

end

 

=={{header|Perl}}==

Code demonstrating shared resources and simple locking. Resource1 and Resource2 represent some limited resources that must be exclusively used and released by each thread. Each thread reports how many of each is available; if it goes below zero, something is wrong. Try comment out either of the "lock $lock*" line to see what happens without locking.

use threads::shared;

 

for ( map async{ use_resource }, 1 .. 9) {

$_->join

 

 

=={{header|PicoLisp}}==

PicoLisp uses several mechanisms of interprocess communication, mainly within

'[http://software-lab.de/doc/refR.html#release release]' function pair

can be used.

 

=={{header|PureBasic}}==

 

'''PureBasic has the following Mutex functions;'''

Result = TryLockMutex(MyMutex)

LockMutex(MyMutex)

UnlockMutex(MyMutex)

 

'''Example'''

Define Mutex

 

UnlockMutex(Mutex)

Next

 

=={{header|Python}}==

a semaphore grants access to a number of threads up to certain value.

 

from time import sleep

 

 

class res_thread(threading.Thread):

 

# after done with resource, return it to pool and flag so

 

# create 4 threads, each acquire resorce and work

for i in range(1, 5):

 

=={{header|Racket}}==

Racket has semaphores which can be used as mutexes in the usual way.

With other language features this can be used to implement new features -- for example, here is how we would implement a protected-by-a-mutex function:

(define foo

(let ([sema (make-semaphore 1)])

(dynamic-wind (λ() (semaphore-wait sema))

(λ() (... do something ...))

and it is now easy to turn this into a macro for definitions of such functions:

(define-syntax-rule (define/atomic (name arg ...) E ...)

(define name

;; this does the same as the above now:

(define/atomic (foo x)

 

But more than just linguistic features, Racket has many additional synchronization tools in its VM.

Some notable examples:

OS semaphore for use with OS threads, green threads, lightweight OS threads, and heavyweight OS threads, synchronization channels, thread mailboxes, CML-style event handling, generic synchronizeable event objects, non-blocking IO, etc, etc.

 

=={{header|Ruby}}==

Ruby's standard library includes a <tt>mutex_m</tt> module that can be mixed-in

to a class.

 

class SomethingWithMutex

include Mutex_m

...

 

Individual objects can be extended with the module too

 

An object with mutex powers can then:

an_object.mu_lock

 

an_object.my_synchronize do

do critical stuff

 

=={{header|Tcl}}==

Tcl's [http://tcl.cvs.sourceforge.net/*checkout*/tcl/thread/doc/html/thread.html#19 mutexes] have four functions.

 

# How to create a mutex

 

# Dispose of the mutex

There are also read-write mutexes available.

 

# Get and drop a reader lock

thread::rwmutex unlock $rw

 

 

=={{header|zkl}}==

zkl has two mutex objects, Lock (mutex) and WriteLock a mutex that allows multiple readers but only one writer.

The critical keyword fences code to ensure the lock is released when the code is done.

lock.acquireForReading(); doSomeReading(); lock.readerRelease();

critical(lock,acquireForReading,readerRelease){ ... }

 

{{omit from|TI-83 BASIC}} {{omit from|TI-89 BASIC}} <!-- Does not have user-defined data structures or objects. -->