Mutex: Difference between revisions

''Side note: During a 6502's NMI, other interrupts cannot occur, not even another NMI. Therefore there is no chance that an IRQ will happen while executing NMI code.''

mutex equ $01 ;these addresses in zero page memory will serve as the global variables.

BEQ again ;this would loop infinitely if it weren't for vblankflag being set during NMI

pla

=={{header|8086 Assembly}}==

* <code>LOCK</code> can't be placed in front of any instruction on the 8086, only ones where it actually applies.

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

MutexCreate, MutexLock, MutexUnlock, MutexDestroy and ThreadCreate.

' If you comment out the lines containing "MutexLock" and "MutexUnlock", the

' threads will not be in sync and some of the data may be printed out of place.

' Clean up when finished

Mutexdestroy(bloqueo_tty)

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

Note: currently J mutexes do not have a meaningful display representation.

name=. 10 T. 1 NB. create a shared (aka "recursive" or "reentrant") mutex

failed=. 11 T. mutex NB. take an exclusive lock on a mutex (waiting forever if necessary)

failed=. 11 T. mutex;seconds NB. try to take an exclusive lock on a mutex but may time out

NB. failed is 0 if lock was taken, 1 if lock was not taken

Recursive mutexes may be locked multiple times -- successive locks increase a counter. When unlocked as many times as previously locked, the mutex is released.

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 {

}

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

=== local mutexes ===

Exclusive-only and non-reentrant.

<span style="color: #008080;">without</span> <span style="color: #008080;">js</span> <span style="color: #000080;font-style:italic;">-- (critical sections)</span>

<span style="color: #004080;">integer</span> <span style="color: #000000;">cs</span> <span style="color: #0000FF;">=</span> <span style="color: #000000;">init_cs</span><span style="color: #0000FF;">()</span> <span style="color: #000080;font-style:italic;">-- Create a new critical section</span>

<span style="color: #0000FF;">...</span>

<span style="color: #000000;">delete_cs</span><span style="color: #0000FF;">(</span><span style="color: #000000;">cs</span><span style="color: #0000FF;">)</span> <span style="color: #000080;font-style:italic;">-- Delete a critical section that you have no further use for</span>

=== global mutexes ===

Using file locking. Only shared locks are reentrant. Every call needs it's own bespoke retry logic. There is no builtin promotion operation.

<span style="color: #008080;">without</span> <span style="color: #008080;">js</span> <span style="color: #000080;font-style:italic;">-- (file i/o)</span>

<span style="color: #004080;">integer</span> <span style="color: #000000;">fn</span> <span style="color: #0000FF;">=</span> <span style="color: #7060A8;">open</span><span style="color: #0000FF;">(</span><span style="color: #008000;">"log.txt"</span><span style="color: #0000FF;">,</span><span style="color: #008000;">"u"</span><span style="color: #0000FF;">),</span>

<span style="color: #0000FF;">...</span>

<span style="color: #7060A8;">close</span><span style="color: #0000FF;">(</span><span style="color: #000000;">fn</span><span style="color: #0000FF;">)</span>

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

Locks are reentrant. You may explicitly lock and unlock them, but the syntax above guarantees the lock will be unlocked on scope exit, even if by thrown exception or other exotic control flow. That being said, direct use of locks is discouraged in Perl 6 in favor of promises, channels, and supplies, which offer better composable semantics.

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

However, to avoid excessive latency, a VM whose thread were continuing would need to signal to the host that it no longer needed the resource so the lock could be released thereby making it available to the other VM(s). Typically, a shared resource might need to be represented something like this in a Wren script:

// obtain a pointer to the resource when available

construct new() {}

var res = Resource.new() // wait for and obtain a lock on the resource

res.doSomething() // use it

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