Mutex: Difference between revisions

[[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|Delphi}}==

{{libheader| Winapi.Windows}}

{{libheader| System.SyncObjs}}

{{libheader| Vcl.StdCtrls}}

unit main;

 

end;

 

{{out}}

<pre>Thread 1

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 ).

 

io:fwrite( " ~p", [X] ),

timer:sleep( 100 ).

{{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}}==

 

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.

From the Julia documentation:

 

Create a non-reentrant lock. Recursive use will result in a deadlock. Each lock must be matched with an unlock.

 

 

Acquire the lock when it becomes available. If the lock is already locked by a different task/thread, wait for it to become available.

Each lock must be matched by an unlock.

 

Releases ownership of the lock.

 

If this is a recursive lock which has been acquired before, decrement an internal counter and return immediately.

 

Acquire the lock if it is available, and return true if successful. If the lock is already locked by a different task/thread, return false.

 

Each successful trylock must be matched by an unlock.

 

Check whether the lock is held by any task/thread. This should not be used for synchronization (see instead trylock).

 

Creates a re-entrant lock for synchronizing Tasks. The same task can acquire the lock as many times as required. Each lock must be matched with an unlock.

 

=={{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>

Using concurrent (in interpreter level), after the execution of one statement, thread change. Using Sequential each thread block run all statements, until end, or leave some if a continue take place. In concurrent also a call to a module, or executing a block of code happen without in one thread.

 

Form 80, 50

Module CheckIt {

\\ 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

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:

 

var mutex: Lock

Locking:

Unlocking:

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

 

=={{header|Objeck}}==

Objeck provides a simple way to lock a section of code. Please refer to the [[Objeck|programer's guide]] for addition information.

 

m := ThreadMutex->New("lock a");

# section locked

}

# section unlocked

 

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

 

 

[m lock]; // locks in blocking mode

}

 

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

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

 

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|Phix}}==

 

=={{header|PicoLisp}}==

 

To create a global mutex:

The recommended way to use the mutex is by wrapping code in a with_mutex/2 call, eg:

This will wrap some code in a mutex to ensure exclusive access and release the mutex on completion (regardless or the result).

 

 

'''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

 

for i in range(1, 5):

t = res_thread()

 

=={{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.

=={{header|Raku}}==

(formerly Perl 6)

 

 

=={{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|Rust}}==

append to a shared string.

 

sync::{Arc, Mutex},

thread,

shared.lock().ok().map_or((), |it| println!("Done: {}", it));

}

 

=={{header|Shale}}==

Shale includes a library that provides POSIX threads, semaphores and mutexes. Below is a really simple example usings threads and one mutex. There's a more complete example that includes semaphores available with the [https://github.com/sharkshead/shale Shale source code].

 

 

thread library // POSIX threads, mutexes and semaphores

 

// Wait a bit to let the threads do their stuff.

 

{{out}}

=={{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. -->