'\" t
.\"     Title: synchronize_srcu
.\"    Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
.\"      Date: May 2018
.\"    Manual: Driver Basics
.\"    Source: Kernel Hackers Manual 3.16.56
.\"  Language: English
.\"
.TH "SYNCHRONIZE_SRCU" "9" "May 2018" "Kernel Hackers Manual 3\&.16\&" "Driver Basics"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
synchronize_srcu \- wait for prior SRCU read\-side critical\-section completion
.SH "SYNOPSIS"
.HP \w'void\ synchronize_srcu('u
.BI "void synchronize_srcu(struct\ srcu_struct\ *\ " "sp" ");"
.SH "ARGUMENTS"
.PP
\fIsp\fR
.RS 4
srcu_struct with which to synchronize\&.
.RE
.SH "DESCRIPTION"
.PP
Wait for the count to drain to zero of both indexes\&. To avoid the possible starvation of
\fBsynchronize_srcu\fR, it waits for the count of the index=((\->completed & 1) ^ 1) to drain to zero at first, and then flip the completed and wait for the count of the other index\&.
.PP
Can block; must be called from process context\&.
.PP
Note that it is illegal to call
\fBsynchronize_srcu\fR
from the corresponding SRCU read\-side critical section; doing so will result in deadlock\&. However, it is perfectly legal to call
\fBsynchronize_srcu\fR
on one srcu_struct from some other srcu_struct\*(Aqs read\-side critical section, as long as the resulting graph of srcu_structs is acyclic\&.
.PP
There are memory\-ordering constraints implied by
\fBsynchronize_srcu\fR\&. On systems with more than one CPU, when
\fBsynchronize_srcu\fR
returns, each CPU is guaranteed to have executed a full memory barrier since the end of its last corresponding SRCU\-sched read\-side critical section whose beginning preceded the call to
\fBsynchronize_srcu\fR\&. In addition, each CPU having an SRCU read\-side critical section that extends beyond the return from
\fBsynchronize_srcu\fR
is guaranteed to have executed a full memory barrier after the beginning of
\fBsynchronize_srcu\fR
and before the beginning of that SRCU read\-side critical section\&. Note that these guarantees include CPUs that are offline, idle, or executing in user mode, as well as CPUs that are executing in the kernel\&.
.PP
Furthermore, if CPU A invoked
\fBsynchronize_srcu\fR, which returned to its caller on CPU B, then both CPU A and CPU B are guaranteed to have executed a full memory barrier during the execution of
\fBsynchronize_srcu\fR\&. This guarantee applies even if CPU A and CPU B are the same CPU, but again only if the system has more than one CPU\&.
.PP
Of course, these memory\-ordering guarantees apply only when
\fBsynchronize_srcu\fR,
\fBsrcu_read_lock\fR, and
\fBsrcu_read_unlock\fR
are passed the same srcu_struct structure\&.
.SH "COPYRIGHT"
.br