Interests, Difficulties, Sentiments, and Tool Usages of Concurrency
A Large-Scale Study on

Mehdi Bagherzadeh Syed Ahmed Srilakshmi Sripathi Raffi Khatchadourian
Mehdi Bagherzadeh Department of Computer Science and Engineering, Oakland University, Rochester, MI, USA

Tel.: +1 (248) 370-2208

Syed Ahmed and Srilakshmi Sripathi Department of Computer Science and Engineering, Oakland University, Rochester, MI, USA

Raffi Khatchadourian Department of Computer Science, City University of New York (CUNY) Hunter College, New York, NY, USA

add1]Mehdi Bagherzadehcor

add1]Syed Ahmed

add1]Srilakshmi Sripathi

add2]Raffi Khatchadourian

[cor]Corresponding author.

[add1]Department of Computer Science and Engineering, Oakland University, MI, USA
[add2]Department of Computer Science, City University of New York, Hunter College, NY, USA

Software developers are increasingly required to write concurrent code that is
However, they find correct concurrent programming challenging.
To help these developers, it is necessary to understand concurrency topics they
are interested in, their difficulty in finding answers for questions in these topics, their
sentiment for these topics, and how they use concurrency tools and techniques
to guarantee correctness.
Interests, difficulties, sentiments, and tool usages of concurrency developers
can affect their productivity.

In this work, we conduct a large-scale study on the entirety of to
understand interests, difficulties, sentiments, and tool usages of concurrency

To conduct this study, we take the following major steps.
First, we develop a set of concurrency tags to
extract concurrency questions and answers from .
Second, we

group these questions and answers into concurrency topics, categories, and a
topic hierarchy.
Third, we

analyze popularities, difficulties, and sentiments of these concurrency topics
and their correlations.
Fourth, we develop a set of race tool keywords to extract concurrency questions
about data race tools

and group these questions into race tool topics.
We focus on data races because they are among the most prevalent concurrency

Finally, we

discuss the implications of our findings for the practice, research, and
education of concurrent software development, investigate the relation of our findings
with the findings of the previous work, and present a set of example questions that developers
ask for each of our concurrency and tool topics as well as categories.

A few findings of our study are:
questions that concurrency developers ask can be grouped into a hierarchy with 27 concurrency topics under 8 major
thread safety is among the most popular concurrency topics and client-server concurrency is among the least popular,
irreproducible behavior is among the most difficult topics

and memory consistency is among the least difficult,
data scraping is among the most positive concurrency topics and irreproducible behavior is among the most negative,

root cause identification has the most number of questions for usage of data race tools and alternative use has the least.

While some of our findings agree with those of previous work, others sharply contrast.

The results of our study can not only help concurrency developers but also concurrency educators and researchers
to better decide where to focus their efforts, by trading off one
concurrency topic against another.

§ INTRODUCTION

Software developers are increasingly required to write concurrent code to satisfy
not only functional but also nonfunctional requirements of their software.
For example, software with a graphical user interface must be
concurrent to satisfy a functional requirement that it should be able to display more than one window at a time.
Similarly, software with timing constraints must be concurrent to be able to satisfy a nonfunctional requirement that

it should provide a better performance.
Software is concurrent if its

computations can  potentially  run at the same time and otherwise is sequential.
In addition to satisfying its functional and nonfunctional requirements, the
concurrent software must be correct. For example, with the initial value of
|x = 0|, the software with the code |x = x + 1|,
that is executed by two concurrent threads, should set the value of
x to 2, which is the correct and desirable value.
However, a concurrency bug, such as a data race bug, can set the value of
x to the incorrect and undesirable value 1.
This data race bug happens when both threads first read
the initial value 0 of x and then increment and set it to
the value 1 separately.
A data race happens when two concurrent computations access
the same variable of the program and at least one of these accesses writes to
the variable.

However, most developers think sequentially and find
writing concurrent programs that are correct
challenging <cit.>.

To help concurrency developers with writing concurrent code that is correct, it
is necessary to understand concurrency topics they are interested in,
their difficulty in finding answers for questions in these topics,
their sentiment for these topics, and how they use concurrency tools and
techniques to guarantee correctness.
Interests, difficulties, sentiments, and tool usages of concurrency developers
can affect their productivity <cit.>.
This understanding can not only help concurrency developers and their practice but also the research and education of concurrent software development by allowing members of these communities to better decide when and where
to focus their efforts
Without such understanding, practitioners may not prepare for similar difficulties,
researchers may make incorrect assumptions about interests  of practitioners, and educators may teach the wrong concurrency topics.

With more than 3 million developer participants and 38 million questions and
answers, written in 2 billion words,
<cit.> has
become a large and popular
knowledge repository for developers to ask questions, receive answers,
and  learn about a broad range
of topics.
This makes a great source to
learn about interests, difficulties, sentiments, and tool usages of concurrency

In this work, we conduct a large-scale study on the entirety of to understand
interests, difficulties, sentiments, and tool usages of concurrency developers
by answering the following research questions:

* RQrqcounter. Concurrency topics What concurrency topics do  developers ask questions about?

* RQrqcounter. Concurrency topic hierarchy
What categories do these concurrency topics belong to?

* RQrqcounter. Concurrency topic popularity What topics are more popular among concurrency developers?

* RQrqcounter. Concurrency topic difficulty What topics are more difficult to find answers to their questions?

* RQrqcounter. Concurrency topic sentiment  What topics are more sentimental among concurrency developers?

* RQrqcounter. Correlations of topic popularity, difficulty & sentiment
Are there correlations between topic popularity, difficulty, and sentiment?

* RQrqcounter. Concurrency tool topics
What topics do developers ask  questions about when using data race tools and techniques?

For tool usage, we focus on the tools for finding and

fixing data race bugs. We focus on data races because data race bugs

are the not only one of the most prevalent bugs in concurrent
software  <cit.> but also

notoriously difficult to find and fix where some of these bugs can have extreme
In a recent emperical study of concurrency bugs,
data race bugs are about half of the concurrency bugs <cit.> in the
open source software. Data races were the culprits in the Therac-25 disaster
<cit.>, the Northeastern electricity blackout of 2003 <cit.>, and the mismatched NASDAQ Facebook share prices of 2012 <cit.>.
Therefore, numerous tools and techniques <cit.> have been developed
to help concurrency developers with data races.

To answer our research questions, we take the following major steps.
First, we develop a set of concurrency
tags to  extract concurrency questions and answers from .
Second, we use topic modeling <cit.> and card sorting <cit.> techniques to group these questions and answers into concurrency topics.
Third, we use card sorting <cit.> to group similar topics into
concurrency categories and construct a topic hierarchy.
Fourth, we use well-known
metrics that are proposed and used by the previous work

to measure the popularities, difficulties, and sentiments of these topics  and analyze their correlations.
Fifth, we develop a set of race tool keywords to extract concurrency questions about data race tools and techniques.
Sixth, we use card sorting to group these questions into race tool topics.
Finally, we discuss the implications of our findings for the practice, research, and education of concurrent software development.
We also investigate the relation of our findings with the findings of
the previous work and present a a set of examples of questions that developers
ask for each of our concurrency and tools topics and categories.

A few findings of our study are:

Concurrency topics
Concurrency questions that developers ask

can be grouped into

27 concurrency topics
ranging from multithreading to parallel computing,
mobile concurrency to web concurrency, and memory consistency to runtime speedup.
itemcounter Developers ask more about the correctness of their concurrent software than their performance.

Concurrency topic hierarchy
Concurrency questions can be grouped into a hierarchy with
8 major categories:
concurrency models, programming paradigms, correctness,
debugging, basic concepts, persistence, performance, and graphical user interface (GUI).

Concurrency topic popularity
Thread safety is among the most popular concurrency topics and client-server concurrency is among the least  popular.

Concurrency topic difficulty

Irreproducible behavior is among the most difficult concurrency topics
and memory consistency is among the least difficult.

Concurrency topic sentiment

Most questions of all concurrency topics are neutral in sentiment.
Data scraping is among the most positive concurrency topics and
process life cycle management is among the least positive.
irreproducible behavior is among the most negative concurrency topics and
process life cycle management is among the least negative.

Correlation of popularity, difficulty and sentiment
There is a statically significant negative correlation between the popularity, difficulty, and negative sentiment of concurrency topics.

Race tool topics
itemcounter Concurrency questions about data race tools can be grouped into 4 topics:
root cause identification, general, configuration & execution, and alternative use.
itemcounter Developers ask the most race tool questions
about root cause identification and the least about alternative use.

Relation of our findings with previous work
Our findings relate to several findings of previous work, including the works by
Pinto <cit.>, Barua <cit.>, Rosen and Shihab <cit.>, Lu <cit.>,
Guzman <cit.>, Sinha <cit.>, Tourani <cit.>, Wang <cit.>, and Bagherzadeh and Khatchadourian <cit.>.
While some of our findings agree with the findings of these previous works,
others sharply contrast.

§.§ Extensions to Our Previous Work

This work is a significantly revised and extended version of our previous work <cit.>
with the following major extensions:

* Addition of the new research question RQ5 and the sentiment analysis of 245,541
concurrency questions and answers for all 27 concurrency topics;

* Addition of the new research question RQ7 and the development of
the race tool keywords, extraction and grouping of race tool questions

into topics, and presenting a set of example questions
that developers ask about race tool topics;

* Extension of our previous research question RQ6 with the analysis
of 15 new correlations between sentiments, popularities, and difficulties of
concurrency topics;

* Extension of our previous implications with the implications of our
new findings for the practice, research, and education of concurrent software development;

* Extension of our previous relations with the relations of our new
findings for

RQ5–RQ7 with the findings of the previous work;

* Extension of our previous data collection with the distribution of concurrency questions and answers over
different programming languages;

* Addition of 10 more findings, to our 12 previous findings, and 10  more relations with the findings of
previous works, to our 16 previous relations;

* Extension of our related work with

previous works related to
the sentiment analysis and usage of data race tools and techniques.

All the data used in this study are available at <https://goo.gl/uYCQPU>.

§.§ Outline

sec:methodology presents our methodology for the collection and analysis of our data.
sec:results discusses the answers to our research questions and
investigates the relation of our findings with the findings of the previous
sec:implications shows the implications of our findings for the practice, research, and education of concurrent software development.
sec:threats discusses threats to the validity of our study and their mitigation strategies.
sec:related discusses related works.
sec:conclusion concludes the paper.

Throughout this paper, the difficulty of a topic is
solely defined as the difficulty for finding  answers to the questions in that

§ METHODOLOGY

fig-methodology shows an overview of our methodology for the collection of concurrency questions and answers from and their analysis.

§.§ Data Collection

Step stepcounter: Download dataset
In this step of our methodology, we download the dataset $\sopostset$
which is publicly available through Stack Exchange Data Dump
The data set $\sopostset$ includes
question and answer posts and their metadata.
The metadata of a post
includes its identifier, its type (question or answer), title, body, tags, creation date, view count, score,
favorite count, and  the identifier of the accepted answer for the post, if the post is a question.
An answer to a question is accepted if the developer who posted the question
marks it as accepted. The question can have at most 1 accepted answer. The
question can have 1 to 5 tags that are used to specify what the question is about.

Our dataset $\sopostset$ includes 38,485,046 questions and answers posted over a time span of over
9 years from August 2008 to

December 2017 by 3,589,412 developer participants of .
Among these posts, 14,995,834 (39%)
are questions and 23,489,212 (61%) are answers. Among these answers
8,034,235 (21%) are marked as accepted answers.

Step stepcounter: Develop concurrency tag set
In this step,
we develop a set of concurrency tags $\tagset$ to identify and extract concurrency
questions and answers in . First, we start with a tag set
$\tagset_{\subscript{init}}$ that includes our initial concurrency tags. Second, we extract questions $\ipostset$
from our dataset $\sopostset$ whose tags match a tag in $\tagset_{\subscript{init}}$. Third, we
construct a set of candidate tags $\tagset$ by extracting tags of the questions
in $\ipostset$. Finally, we refine $\tagset$ by keeping tags that are significantly
relevant to concurrency and exclude others. We use two heuristics $\sig$
and $\rela$, that are also used by the previous work
<cit.>, to measure the significance and
relevance of a tag $t$ in $\tagset$.

(Significance)   = number of questions with tag $t$ in $\ipostset$number of questions in $\ipostset$

(Relevance)     = number of questions with tag $t$ in $\ipostset$number of questions with tag $t$ in $\sopostset$

A tag $t$ is significantly relevant to concurrency if its $\sig$ and $\rela$ are higher
than specific thresholds.
Our experiments using a broad range of thresholds for $\sig$ and $\rela$ show that
$\mu=0.1$ and $\nu=0.01$ allow for a significantly relevant set of concurrency tags.
Our threshold values
are in line with the values
used by previous work <cit.>.

fig-tags shows the concurrency tag set $\tagset$ for select significance and relevance
values $\sig$ and $\rela$ with our tagset
$\canset$ in gray.

$\canset$= {    concurrency locking multiprocessing multithreading mutex

$~~$parallel-processing pthreads python-multithreading

synchronization task-parallel-library thread-safety threadpool$~$}

We use the initial tag set $\tagset_{\subscript{init}}=\{\btag{multithreading}\}$ to construct the tag set  $\tagset$ below
using our tag development approach.
To select the set of our initial tags in $\tagset_{\subscript{init}}$,
we manually inspect the top 100 most used tags on and select all the tags that are related to concurrency.
Our set $\tagset_{\subscript{init}}$ includes a tag multithreading, that
is used by  previous work <cit.> as well.

\[
\canset = \left\{ \begin{array}{p{10.5cm}}
\emph{concurrency locking multiprocessing multithreading mutex}
\emph{parallel-processing pthreads python-multithreading}
\emph{synchronization task-parallel-library thread-safety threadpool}
\end{array}\right\}
\]

Our concurrency tag set $\canset$ with 12 tags is broad and includes generic tags, such as concurrency and synchronization,
and specific tags, such as

thread safety and thread pool

Step stepcounter: Extract concurrency posts
In this step,

we extract questions whose tag set
contains a tag in $\tagset$.
This set includes 156,777 questions and 249,662 answers, where 88,764 (36%)
of these answers are accepted answers.
To reduce noise, following previous work <cit.>, we add questions and their accepted answers from this set to
our set of concurrency post $\cpostset$ and discard unaccepted answers.
The set of concurrency posts $\cpostset$ includes 156,777 questions and 88,764 accepted answers. In total,
$\cpostset$ includes 245,541 questions and answers.

Using the tag set $\canset$ to extract concurrency questions
does not mean that concurrency questions cannot have other tags in addition to
the tags in $\canset$.

In fact, our concurrency questions have 11,703 extra tags, such as
asynchronous, blocking, and atomic.

addition, our concurrency questions are related to a broad spectrum of
programming languages ranging from C languages, such as C, C++, C#, and
Objective C, to Java and JavaScript and from Visual Basic to Go and
fig-languages shows the number of our concurrency questions for
different programming languages. To extract these languages, we manually inspect
top 200 most used tags in $\cpostset$ and select tags that identify a
programming language.

Step stepcounter: Develop race tool keyword set
In this step, we develop a set of keywords $\kset$ to identify and extract concurrency questions
that are about tools and techniques that are used to find and
fix data race bugs.

We develop a keyword set instead of a tag set

because of the following reasons. First, there are no tags that
are specifically designed to represent data race tools and techniques.
Second, most questions with the
generic data race tags <cit.>, such as data-race and
race-condition, are not about the usage of data race tools and

To construct the keyword set $\kset$, we include the names of both industrial
as well as academic data race tools and techniques that are discussed in
the previous work.

For industrial tools, we include Google's ThreadSanitizer (TSan)
and ThreadSafety  (annotalysis) <cit.>, Intel's Inspector <cit.>,
and Valgrind's Helgrind and DRD <cit.>.
For academic tools and techniques, we add 29 tools and techniques from a recent and comprehensive survey on  data race tools and techniques <cit.>.
We exclude tools and techniques with no specific names or overly generic names such as HAVE.

\[
\kset = \left\{ \begin{array}{p{10.5cm}}
\emph{ThreadSanitizer TSan ThreadSafety annotalysis Helgrind}
\emph{DRD 'Intel Inspector' Acculock Eraser FastTrack LiteRace Racer}
\emph{RaceTrack RACEZ SOS TRaDe Atom-Aid AtomRace AVIO}
\emph{CTrigger DefUse FALCON McPatom PENELOPE MultiRace}
%        &\emph{MUVI-Eraser AtomTracker ColorSafe COPPER HAVE Marathon}\\
\emph{MUVI-Eraser AtomTracker ColorSafe COPPER Marathon}
\emph{MUVI-AVIO Veldrome Chord RacerX RccJava RELAY}
\end{array}\right\}
\]

$\kset$= {
ThreadSanitizer TSan ThreadSafety annotalysis Helgrind

DRD 'Intel Inspector' Acculock Eraser FastTrack LiteRace Racer

RaceTrack RACEZ SOS TRaDe Atom-Aid AtomRace AVIO

CTrigger DefUse FALCON McPatom PENELOPE MultiRace

MUVI-Eraser AtomTracker ColorSafe COPPER Marathon

MUVI-AVIO Veldrome Chord RacerX RccJava RELAY}

The keyword set $\kset$ with 36 keywords covers a broad set of static and dynamic

tools and techniques for finding and fixing data race bugs.
To illustrate, Chord and RacerX are static whereas ThreadSanitizer and ThreadSafety are dynamic.
A static race detection technique analyzes a program without running it, whereas a dynamic technique

analyzes the runtime information of the program.

Step stepcounter: Extract race tool posts
In this step, we first extract concurrency questions from $\cpostset$ that their title or body include a keyword in $\kset$.
This set includes 446 questions. Second, we manually study these questions to exclude the questions that are not about
data race tools.
This is because a keyword in $\kset$ may refer to different tools and techniques

used for

different purposes.
To illustrate, FALCON is not only a data race tool but also a Python web development framework.

Similarly, Helgrind can not only be used for race detection but also deadlock.
Our final set $\uset$ of race tool posts includes 82 questions. Interestingly, the questions in $\uset$ are related to the
following 6 keywords in $\kset$ and

there are no questions in  $\uset$ for the rest of keywords.

{ThreadSanitizer TSan Helgrind DRD 'Intel Inspector' CTrigger RacerX}

\[
\left\{ \begin{array}{p{11cm}}
\emph{ThreadSanitizer TSan Helgrind DRD 'Intel Inspector' CTrigger RacerX}
\end{array}\right\}
\]

Step stepcounter: Preprocess concurrency posts

In this step, we preprocess the set of our concurrency posts $\cpostset$ to
reduce the noise for sentiment analysis and topic modeling in the next steps.

For sentiment analysis, we preprocess $\cpostset$

by removing code snippets,
enclosed in $\left<code\right>$$\left<\backslash code\right>$ tags, HTML tags, such as $\left<p\right>$ $\left</p\right>$,
numbers, punctuation marks, non-alphabetical characters, and URLs.
For topic modeling, we further preprocess $\cpostset$

by removing

stop words, such as “a”, “the”, and “is”, and reduce words to their base representations. For example,
“reading”, “read” and “reads” all reduce to their base “read”. Reducing words to their bases allows grouping of words with
similar meanings together.

For stop words
and word reduction, we use  's popular list of stop words <cit.> and Porter stemming algorithm <cit.>, respectively.
We do not

reduce words for sentiment analysis because an unreduced

word may convey important
sentiment information <cit.>.

§.§.§ Data collection for concurrency questions and answers

Our data collection steps are in line with the best practices of
previous work.
Previous work uses tags, keywords, and significance and relevance heuristics
often to identify security <cit.>, chatbot <cit.>,
mobile <cit.>, big data <cit.>, and deep learning
<cit.> questions and answers from .

§.§ Data Analysis

Step stepcounter: Model and label concurrency topics
In this step,

we use  <cit.> with latent Dirichlet allocation (LDA)  topic modeling <cit.>
to group our concurrency posts  $\cpostset$ into topics.

In our topic model, a concurrency post is a probabilistic distribution of several topics
with different proportions.
A post has a dominant topic that covers the biggest
proportion of the text of the post. A topic is a set of frequently co-occurring
words that approximates a real-world concept.
To produce the model, we treat each individual question and accepted answer  as an
individual document. processes 245,541 questions and answers documents.

posts into $K$ topics after $I$ grouping iterations and returns a set of
topics and their proportions for each post along with a set of words for
each topic.

Our experiments with a broad range of values

show that $K=30$ and $I=1,000$

allow for sufficiently granular topics.
These values are in line with values used by previous work
MALLET uses hyperparameters $\alpha$ and $\beta$ to control the distribution of words
in topics and distributions of topics in posts.
Following previous work <cit.>, we use standard values
50/K and 0.01 for these hyperparameters. We use this standard values

because as Bigger et al.
<cit.> show "$\alpha$ and $\beta$ have little influence on the accuracy of the LDA [topic modeling]".

groups concurrency posts  $\cpostset$ into topics $t$ that are a set
of words. However, cannot decide about the meaning of the topics and
label them with names useful for human beings.
To illustrate, the word set $w = \{task,$ $execute,$ $async,$ $complete,$ $run,$ $cancel,$ $wait,$ $asynchronous,$ $parallel,$ $schedule\}$
represents a topic in .

Following previous work <cit.>, we
use an open card sort technique <cit.> to label the topics.

In an open card sort, there are no predefined topics and participants develop their own topics during the sorting and labeling process.
To label a topic, we find it sufficient to manually inspect the top 20 words in the set of words for
the topic and read through 15 random posts for the topic to decide for
a label that best explains the words and posts of the topic.
To illustrate, we label the word set $w$ with task parallelism.
The numbers of topic words and random posts used to label
a topic are in line with previous work
fig-topics shows our 27 concurrency topics, their names,
and top 10 reduced words.

During the labeling process, we merge topics 1 and 15 into basic concepts topic due to
close similarities between their topic words and questions.
Similarly, we merge topics 5 and 28 into object-oriented concurrency.

We remove topic 12

that is about synchronization between local and remote repositories in version control systems
such as Git and is not about concurrency.

During the card sorting process for concurrency topics, the first and second authors individually assign labels to topics and reiterate and refine topics
until they agree on topic labels.

The first author is a Programming Languages and Software Engineering professor
with extensive expertise in concurrent and event-based systems
and the second author is a graduate student with coursework in concurrent and distributed systems.
The first author also has several years of industrial experience  as a Software Engineer.

Step stepcounter: Construct concurrency topic hierarchy
In this step, we use a card sorting process, similar to the step 7 and with the
same authors, to

construct the topic hierarchy by repeated grouping of similar topics into categories,
and lower-level categories into higher-level categories.
There are no predefined

categories and and
participants develop their own categories during the sorting and labeling
process. fig-topics and  fig-posts-sunburst show the textual and pictorial representations of the topic hierarchy.
To illustrate, thread life cycle management and thread
scheduling topics are grouped into the lower-level  category multithreading, where multithreading itself is grouped into the higher-level category concurrency models.
The category concurrency models includes other lower-level categories such as

multiprocessing and parallel computing.

Step stepcounter: Determine concurrency topic popularity
In this step, we use 3 well-known metrics that are used often by the previous
work to measure the popularity of a concurrency topic.

The first metric, that is used by the previous work
is the average number
of views for questions with the topic as their dominant topic.
This metric includes views by both registered users and visitors of .
The inclusion of views by visitors is important because in there are
many more visitors than there are registered users <cit.>.
The second metric, that is used by the previous work
is the average number of questions of the topic marked as favorite by users.
The third metric, that is used by the previous work
<cit.>, is the
average score of questions of the topic.
Intuitively, a topic with a higher number of views and favorites and a higher score is more popular.
fig-topic-pop-table shows the popularity measurements of concurrency topics.

Step stepcounter: Determine concurrency topic difficulty

We use 2 well-known metrics that are used often by previous work to measure the
difficulty of a concurrency topic.
The first metric, that is used by the previous work
<cit.>,  is the
percentage of questions of the topic that have no accepted answers .
And the second metric, that is used by the previous work
<cit.>, is the average median time
needed for a question to receive an accepted answer.
Intuitively, a topic with  higher percentage of questions with no accepted
answers and taking longer to receive accepted answers is more difficult.
fig-topic-diff-table shows the difficulty measurements of our concurrency topics.

Step stepcounter: Determine concurrency topic sentiment
We use <cit.> to determine
the sentiment of our concurrency topics.

uses a combination of
lexical and semantic features to determine the sentiment polarity of a concurrency post and
classify it as positive, negative, or neutral.
For example, classifies the sentence
“I am so used to thinking about solutions in a linear/serial/OOP/functional way
that I am struggling to cast any of my domain problems in a way that merits
using concurrency” from a post as negative whereas it classifies the
sentence “what challenges promote the use of parallel/concurrent architectures?” as

specifically trained
to analyze communications of software developers. Previous work
<cit.> shows that provides the best
performance, in comparison to other sentiment analysis tools such SentiStrength <cit.>, SentiCR <cit.>, and
SentiStrengthSE <cit.>,

when analyzing questions and answers.

The sentiment of a concurrency topic is the percentages of the positive, negative, and neutral polarities of its questions and answers.
fig-topic-sent-table shows the sentiment measurements of concurrency

Step stepcounter: Determine popularity, difficulty, and sentiment correlations
In this step,

we use Kendall correlation to identify if there are any correlations between

popularity, difficulty, and sentiment of our concurrency topics.

We use Kendall because it is less sensitive to outliers and is relatively more stable.
In total, we investigate 21 correlations between 3 popularity, 2 difficulty, and
3 sentiment metrics of our concurrency topics.

Step stepcounter: Label race tool topics
In this step, we use the card sorting technique, similar to steps 7 and 8,
to group race tool questions in $\uset$ into race tool topics.
During the card sorting process, the first and
fourth authors individually assign labels to topics and reiterate and refine the
topics until they agree on topic labels.

The fourth author is a Software Engineering professor
with extensive expertise in parallel systems <cit.>.
The fourth author also has several years
of industrial experience as a Software Engineer.

Step stepcounter: Investigate the relation of our findings
with the findings of previous work Throughout steps  7–13 of our analysis, we
investigate the relation of our findings
in each of these steps with the findings of previous work.

§.§.§ Data analysis of concurrency questions and answers

Our data analysis steps are in line with the best practices of
previous work.
Previous work uses card sorting and manual analysis often to
group security <cit.>, chatbot <cit.>,
mobile <cit.>, big data <cit.>, and deep learning
<cit.> questions and answers from .
In addition, previous work uses the average number of views, favorites, and scores as popularity metrics and
the percentage of questions with no answers and median time to receive
accepted answers as difficulty metrics to
measure the popularity and difficulty of security <cit.>, chatbot <cit.>,
mobile <cit.>, and big data <cit.> topics.

§ RESULTS

In this section, we present and discuss the results of our study for
research questions

investigate the relation of our findings
with the findings of the previous work, and

present a set of
example questions that developers
ask for each of our concurrency and race tool topics and categories.

§.§ RQ1: Concurrency Topics

fig-topics shows the concurrency topics that developers ask questions
about on . These topics are determined in step 7 of our analysis.

According to fig-topics,
developers ask questions about a broad spectrum of concurrency topics.
These questions can be categorized into 27 concurrency topics

from thread pool to parallel computing, mobile concurrency to web concurrency, and
memory consistency to runtime speedup.

The meaning of a concurrency topic is best understood by looking at

the questions that belong to the topic.
To illustrate, the following is a question in the thread pool topic.
In this question,

the developer is asking
how to implement a thread pool

where the size of the pool can change based on the number of its jobs.

The identifier for this question is 11249342 and
can be accessed at <https://stackoverflow.com/questions/11249342>.
This question has been viewed 13,448 times, more than 6 times
the average number of views for a question. The
average number of views for a question is 2,154 <cit.>.

A thread is an abstraction for the execution of a computation that allows to control its

by running, suspending, and resuming the execution of the computation.

A thread pool is an abstraction for a set of threads that allows for their creation, allocation, and deallocation.
11249342Creating a dynamic (growing/shrinking) thread pool
I need to implement a thread pool in Java (java.util.concurrent) whose number of threads is at some minimum value when idle, grows up to an upper bound (but never further) when jobs are submitted into it faster than they finish executing, and shrinks back to the lower bound when all jobs are done …How would you implement something like that? …

Similarly, the following is a question in the web concurrency topic.
In this question,

the developer is asking
how to send emails using background threads in their web application where the background thread
prevents blocking of the main thread and therefore does not force the user to wait until the email is sent.

Classic ASP (Active Server Pages)

is a scripting language to write server-side web applications.
Ajax is a client-side web development technique
for asynchronous communication between a web client and server.

In an asynchronous request, the client does not block to wait for the response from the server and can immediately continue
its computation after the request is made.

17052243How to perform multithreading/background process in classic ASP
I need to send emails via a background job on a classic-ASP app so the user doesn't have to wait for a slow webserver to complete sending the email.
I know I can use Ajax to generate two separate requests, but I'd rather not require Javascript. Plus, I suspect there's a better way to pull this off. Ideas?

Finally, the following is a question in the basic concepts topic. In
this question, the developer asks about the basic motivations behind the
need for concurrency and concurrency architectures.
541344What challenges promote the use of parallel/concurrent architectures?
.. I am so used to thinking about solutions in a linear/serial/OOP [Object-oriented Programming]/functional way that I am struggling to cast any of my domain problems in a way that merits using concurrency.

Questions that concurrency developers ask can be grouped into 27 concurrency

from thread pool to parallel computing, mobile concurrency to web concurrency, and
memory consistency to runtime speedup.

fig-topic-question shows the number of questions that developers ask about our concurrency topics.

According to fig-topic-question,

the numbers of questions that developers ask for concurrency topics are not uniform.
Developers ask the most number of questions (8) about basic concepts and
the least number of questions (1) about event-based concurrency.

(Pinto and Rosen and Shihab)
Pinto <cit.> study the 250 most popular concurrency questions on
and group them into several themes.

Our observation that the concurrency topic basic concepts has the most number of questions
is similar to Pinto 's observation that “most of them [concurrency
questions] are related to basic concepts”.
Our observation is also in line with the general understanding that the concurrency
and even its basics remains challenging for developers.
Bagherzadeh and Khatchadourian <cit.> study and categorize questions and answers related to
big data software development into several big data topics and categories including the basic concepts topic.
Our basic concepts topic overlaps with Bagherzadeh and Khatchadourian's
basic concepts.

Interestingly, both concurrency and big data developers ask more than average number of questions about basic concepts.

Developers ask the most

questions about basic concepts inline with the general
understanding that the concurrency and even its basics remains challenging for
developers. Developers ask
the least

about event-based concurrency.

§.§ RQ2: Concurrency Topics Hierarchy

fig-posts-sunburst shows the hierarchy of our concurrency topics.
This hierarchy is constructed in step 8 of our study.
In this figure, concurrency topics are in gray and their categories are in white with the percentages of their questions. The
hierarchy expands outwards from higher-level to lower-level categories to topics.

According to fig-posts-sunburst,
questions that concurrency developers ask can be grouped into a hierarchy with

8 high-level categories:
concurrency models, programming paradigms, correctness,
debugging, basic concepts, persistence, performance, and graphical user interface (GUI).

In addition, the number of questions that developers ask in each category is not
Developers ask the most 28 about the concurrency models and the least 5 about GUI.

Interestingly, developers ask more 12 about correctness of
their concurrent programs than performance 7.
This is in line with the general tradeoff between the performance advantages of
concurrency and its correctness issues <cit.>.

Questions that

developers ask can be grouped into a hierarchy with
8 high-level categories:
concurrency models, programming paradigms, correctness
debugging, basic concepts, persistence, performance, and GUI.

Developers ask the most questions

about concurrency models category and the least

about GUI.

Developers ask more

about correctness than performance,

in line with the correctness and performance tradeoffs of concurrent software.

In the following, we discuss each higher-level concurrency category and
its lower-level categories and topics. In addition, we present a set of
example questions for each concurrency topic and category.

§.§.§ Concurrency Models

Concurrency models are

concerned about concurrency abstractions (e.g. threads and processes)
and execution models (e.g. multicore and single core executions).

The concurrency models category includes five lower-level categories among which
multithreading alone contains more than half of the questions that developers ask in this category.

This is in line with the general understanding that
multithreading is the defacto dominant concurrency model.

Developers ask the most (54) about multithreading and the least (6) about
producer-consumer concurrency, when asking questions about concurrency

In multithreading,

developers ask questions with titles like
thread life cycle managementHow to safely destruct Posix thread pool in C++? and

thread poolIs there a way to create a pool of pools using the Python workerpool module?.
The topic of a question is included inside parentheses.

producer-consumer concurrency, developers ask questions with titles like
producer-consumer concurrencyproducer Consumer with BlockingQueues in Java EE as background task.

Our multithreading category and its thread life cycle management topic

overlap with Pinto 's <cit.> threading and thread
life cycle themes.
Rosen and Shihab <cit.> study and categorize questions related to mobile development
into several mobile topics including threading.
Our multithreading category  overlaps with their mobile threading

Developers ask the most

about multithreading, when asking about concurrency models,
in line with the general understanding that multithreading is the defacto
dominant concurrency model.

Developers ask the least

about producer-consumer concurrency.

§.§.§ Programming Paradigms

Programming paradigms are  concerned about programming abstractions (e.g. objects and events), platforms (e.g. web and mobile), and
patterns (e.g. producer and consumer).
The programming paradigms category includes five lower-level categories among which
object-oriented concurrency alone contains more than a third of questions that developers ask in this category.
This is in line with the general understanding that object-orientation is a
dominant programming paradigm.
Developers ask the most (35) about
object-oriented concurrency and the least (6) about
event-based concurrency, when asking about programming paradigms.

In the object-oriented concurrency and event-based concurrency topics, developers ask
questions with titles like object-oriented concurrencyIs it better to synchronize object from inside of the class that encapsulates access it or from outside?
and event-based concurrencyWhat type of timer event should I use for a background process when my timer fires very quickly?.

Barua <cit.> study and categorize all questions and answers into several general topics including
web and mobile development. Our concurrency topics mobile concurrency
and web concurrency overlap with their general  web development and
mobile development topics.
Our mobile concurrency topic overlaps with Pinto 's
<cit.> observation that “concurrent programming has reached mobile developers”.

Pinto 's  <cit.> study, 9 of questions are related to mobile development.
In contrast, according to fig-topic-question,
only 4.6 of our concurrency questions are in mobile concurrency

Developers ask the most

object-oriented concurrency, when asking about programming
paradigms, in line with the
general understanding that object-orientation is a dominant concurrent
programming paradigm.

Developers ask
the least

about event-based concurrency.

§.§.§ Correctness

Correctness is concerned with the prevention of data corruption for concurrently accessed (e.g. read and write) data using
mechanisms like locking, consistent memory models, and thread-safe data structures and programming patterns.
Correctness questions are divided almost evenly among its
thread safety, locking, concurrent collections, and memory consistency topics.

In correctness category, developers ask questions like
thread safetyHow to make factory [pattern] thread safe?,
lockingIs there a way to lock 2 or more locks or monitors atomically?,
concurrent collectionsThreadsafe dictionary that does lookups with minimal locking,
and memory consistencyAtomic read-modify-write in C#.

Lu <cit.> categorize concurrency bug patterns and their fixes.
Our memory consistency topic overlaps with their observations that most
concurrency bugs are atomicity violation bugs where the
"desired serializability among multiple memory accesses is violated" and order violation bugs where
the "desired order between two (groups of) memory accesses is flipped."
Our locking topic overlaps with their designation that locking is one of
the main fixes for concurrency bugs to ensure correctness.

In addition, our correctness category and its locking topic
overlap with Pinto 's <cit.> correctness and
locking themes.
Similarly, our concurrent collections topic overlaps with Pinto 's
concurrent libraries theme.

Correctness questions are divided almost evenly between
thread safety,
concurrent collections,
and memory consistency topics.

§.§.§ Basic Concepts

Basic concepts are about

both theoretical and practical aspect of concurrency and includes questions with

titles like How many threads are involved in deadlock?,
What is a race condition?,
Lock, mutex, semaphore... what's the difference?,
and Java: notify() vs. notifyAll() all over again.

Our basic concepts category overlaps with Pinto 's <cit.>
theoretical concepts and practical concepts themes.

§.§.§ Debugging

Debugging is concerned about finding and fixing concurrency bugs which manifest either in the behavior or output of programs.
Debugging questions are almost evenly divided among its topics irreproducible behavior
and unexpected output, which includes

question with titles like
irreproducible behaviorTrace non-reproducible bug in C++
and unexpected outputSynchronized codes with unexpected outputs.

Our debugging category overlaps with Bagherzadeh and Khatchadourian's
<cit.> big data debugging topic.

Our irreproducible behavior topic in debugging category overlaps
with Lu 's  <cit.> observation that some ”concurrency bugs are very difficult to repeat”.

Debugging questions are divided almost evenly
between irreproducible behavior and unexpected output topics.

§.§.§ Persistence

Persistence is about storing and retrieving of data using persistence management systems (e.g. databases management systems,
entity/object persistence[An entity management system automates the serialization of objects (entities) for storage in a database.]

or file systems).

Persistence includes three topics among which database management systems  includes near half of persistence questions.

The persistence category includes question
with titles
database management systemHow do I lock read/write to MySQL tables so that I can select and then insert without other programs
reading/writing to the database?,
file managementIs this is correct use of mutex to avoid concurrent modification to file?,
and entity managementSave entity using threads with JPA [Java Persistence API] (synchronized).

Our database management systems topic overlaps with Barua 's
<cit.> general MySQL topic.

Nearly half of persistence questions are about database management systems.

§.§.§ Performance

Performance is about speeding up execution of programs (e.g. data scraping programs[A data scraping program downloads data from remote web URLs and stores it locally.]).

Performance includes two topics. These topics includes questions with titles like
runtime speedupPoor multithreading performance in .Net
and data scrapingUsing multithreading to speed up web crawler written by beautifulsoup4 and python.

Pinto <cit.> observe that

“did not find questions that ask for advices on
how to use concurrent programming constructs to improve
application performance, which is surprising, since performance is one of the most important motivations for the use
of concurrency and parallelism”.
In contrast, according to fig-topics-questions, our performance topic
includes more than 7 of all of our concurrency questions.
In addition, our performance topic overlaps with Bagherzadeh and
Khatchadourian's <cit.> big data performance topic.

§.§.§ GUI

Graphical user interface (GUI) allows for the graphical interaction between a software and its users.
GUI is the smallest category with regard to the number of questions and includes question with titles like
Force GUI update from UI Thread and Object synchronization with GUI Controls.

Our concurrency topic GUI overlaps with Rosen and Shihab's
<cit.> UI topic for mobile programming.

§.§ RQ3: Popularity of Concurrency Topics

fig-topic-pop-table shows the popularities of our concurrency topics.
These popularities are meausured using 3 metrics average number of
views, favorites and score, in step 9 of our analysis.
fig-topic-pop-table is sorted by the average number of views
for topics and the highest and the lowest values of popularity metrics are in gray.  A topic
with higher number of views, favorites, and score is more popular.

According to fig-topic-pop-table, the thread safety topic has the highest views, third highest favorites, and second highest score
whereas client-server concurrency has the third lowest views and lowest favorites and score.

Thread safety topic, in correctness category, and
client-server concurrency, in programming paradigms, are among
the most and least popular concurrency topics, respectively.

§.§ RQ4: Difficulty of Concurrency Topics

fig-topic-diff-table shows the difficulty of concurrency topics. These
difficulties are measured using 2 metrics percentage of questions with no
accepted answers and average median time to get an accepted answer, in step
10 of our analysis. fig-topic-diff-table is sorted by the percentage of
questions with no accepted answers and the highest and the lowest values of difficulty metrics are
in gray.  A topic with a higher percentage of questions with no accepted
answers and median time to receive accepted answers is more difficult.

According to
fig-topic-diff-table, the irreproducible behavior topic has the second highest percentage of questions with no accepted
answers and highest time to accepted answers whereas memory consistency has the lowest percentage of questions with no accepted answers and
the second lowest time to accepted answers.

Irreproducible behavior topic, in  debugging category, and
memory consistency, in correctness, are among the most and least
difficult concurrency topics, respectively.

§.§ RQ5: Sentiment of Concurrency Topics

fig-topic-sent-table shows the sentiment of concurrency topics.
These sentiments are measured

using percentages of their positive, neutral, and
negative polarities, in step 11 of our study.
fig-topic-sent-table is sorted by the positive polarity and the highest and lowest
values of polarities are in gray.

A topic is neutral if its neutral polarity is higher than its positive and negative polarities.
The positive and negative topics are defined similarly.

According to fig-topic-sent-table, the neutrality of all concurrency topics is higher than their positivity and negativity.
That is, all concurrency topics are neutral in sentiment.
Process life cycle management and irreproducible behavior are the most and least neutral topics.
Data scraping and

process life cycle management topics are the most and least positive whereas
irreproducible behavior and process life cycle management
are the most and least negative.

Interestingly, in sentiments, the  most positive is not the same as the least negative.
For example, data scraping is the most positive topic but not the least negative.
The same is true for the least positive and most negative sentiments.

Guzman <cit.> analyze the emotions of commit logs in
29 general GitHub projects. Our observation that all concurrency topics are neutral

is similar to Guzman 's observation that “the average emotion score
of the commit comments for each of the projects tended to neutrality”.
Similarly, Sinha <cit.> analyze the sentiment of 2,251,585
commit logs in 28,466 general GitHub projects.
Our observation is also similar to Sinha 's observation that “a
majority [74.74] of the sentiment in GitHub projects are categorized as neutral”.
Tourani <cit.> analyze emotions of 595,673 developer and user emails from Apache's Ant and Tomcat mailing lists.
Finally, our observation is similar to  Tourani 's observation that
“19.77% of the sampled emails were positive, 11.27% negative. [And, 68.95% were neutral]”.

findingcounterAll concurrency topics are neutral in sentiment.

Data scraping and  process life cycle management topics are the most and least positive whereas
irreproducible behavior and process life cycle management
are the most and least negative.

§.§ RQ6: Correlations of Popularity, Difficulty, and Sentiment

According to Tables <ref>-<ref>,
a topic like client-server concurrency has lower popularity, higher difficulty, and a more negative sentiment.
Such anecdotal evidence could suggest an intuition that there may be correlations between
the popularity, difficulty, and sentiment of concurrency topics where a less popular topic is more difficult and more negative.

To investigate, we calculate 21 correlations between 3 popularity, 2 difficulty, and 3 sentiment metrics of
our concurrency topics. These correlations are calculated in step 12 of our analysis.

fig-correlations-extend shows the p-values and directions (positive or negative) of these correlations.

According to fig-correlations-extend, there is a statically significant negative correlation with 95% confidence between
the popularity

and difficulty metrics of concurrency topics, except for the average number of favorites popularity metric
and the hours to accepted answer difficulty metric.

That is, more popular concurrency topics are usually less difficult to find answers to their questions.
Similarly, there is a  statically significant negative correlation between the popularity metrics and negative sentiment of
concurrency topics, except for the average number of views popularity metric and the negative sentiment. That is, more popular topics
are usually less negative.

Note that these correlation

do not imply causality.

Pinto <cit.> study 300  questions and 550 answers related to
software energy consumption on and group them into several themes.
Our observation that the more popular concurrency questions are less difficult
to find answers for
is in constrast to Pinto 's observation that their
Measurement theme is not only their most difficult theme but also the
most popular. Our observation is also in contrast to Rosen and Shihab's
<cit.> observation that finds  Barua 's
<cit.> popular mobile development topic to be difficult.

Wang <cit.> study the relation between time to answer a question with 46 factors of questions, answers, askers, and answerers
in 55853, 70336, 7134, and 10776 questions on 4 question and answer websites
Stack Overflow, Mathematics, Super User, and Ask Ubuntu.
Our observation

is also similar to Wang 's observation that “slow-answered
[more difficult] questions are usually associated with rarer [less popular]
tags than fast-answered questions across the four studied websites”.

More popular concurrency topics are usually less difficult and less negative.

§.§ RQ7: Race Tool Topics

fig-tool-usage shows the race tool topics that concurrency developers
ask questions about on . These topics are determined in step 13 of our analysis.

According to fig-tool-usage, the questions that developers ask about race tools

can be grouped into

4 topics:

root cause identification, general,  and alternative use.
In addition, the number of questions that developers ask in each topic is not uniform.
Developers ask the most questions (68)
about root cause identification
and the least (9) about alternative use of race tools.

Questions that concurrency developers ask about race tools can be

grouped into 4 topics root cause identification, general,  and alternative use.

Developers ask the most number of race tool questions about root cause identification and
the least about alternative use.

In the following, we discuss race tool topics and present a set of
example questions for each topic.

§.§.§ Root Cause Identification

Root cause identification is about using the output of  race detection tools to identify
the source of the reported races in the code.

Root cause identification could become challenging because of the high
false positive rate, buggy behavior of the tools, and the difficulty in understanding their outputs.
More than two thirds of race tool questions are about root cause
identification. This is in line with the general understanding that
root cause identification is a major step when debugging software systems.
Root cause identification include questions

36127075ThreadSanitizer says my Atomic Inc/Dec has data races, false positive?,
11564606Why does valgrind drd think pthread_barrier_wait is buggy?,
19140720intepretation of Valgrind output to figure out the location of data race, and
3035313Can't figure out where race condition is occuring.

Sadowski and Yi <cit.> study the use of widely used ThreadSafety and Thread Sanitizer (TSan) concurrency
tools at Google and identify
tool usage themes

by interviewing
7 developers.

Our observation that developers are concerned about false positives in root cause identification
is similar to Sadowski and Yi's observation that “another theme that
repeatedly emerged was the importance of a low false positive rate”.

More than two thirds of race tool questions are about root cause identification,
in line with the general understanding that root cause identification is a major debugging step.

§.§.§ General

General topic is about fundamental guarantees, features, and best practices of race tools

and includes question with titles like
19090583Does one run of Helgrind suffice to guarantee that the given multithreaded implementation is data-race free and deadlock-free?,
41316700What features does threadsanitizer lack that are supported by helgrind, and vice-versa?, and

2444787What threading analysis tools do you recommend?.
Interestingly, about 1 in 7 (13.5) of questions that developers ask about race tool are general questions.
This means that usage of race tools and even their basics remains challenging for developers.

Near 1 in 7 questions that developers ask about race tools are general questions which means that
the usage of race tools and even their basics remains challenging for concurrency developers.

About 1 in 7 race tool questions are general questions.

§.§.§ Configuration and execution

Configuration and execution is about the proper configuration and
execution of race detection tools for different execution environments (e.g.

operating systems and frameworks). Configuration and execution includes

like 26997392Is there a way to run
helgrind/drd in android?,
19770250valgrind/helgrind gets killed on stress test,
and 10134638Valgrind hanging to profile a multi threaded program.
About 1 in 10 race tool questions are about .

Our configuration and execution
topic overlaps with Bagherzadeh and Khatchadourian's <cit.> big
data configuration category.

About 1 in 10 race tool questions are
about .

§.§.§ Alternative Use

Alternative use is about using race tools not only to detect races but also
to monitor, trace, and profile concurrent software for its behavior and performance.
Alternative use includes questions

9014180How to monitor each thread behavior of a multithread (pthread) C++ program on Linux?,
44085032Trace non-reproducable bug in c++,
1963960How to measure lock contention?, and
25288400How can I debug what portion of a multi-threaded C++ program is taking excessive time?.
About 1 in 10 race tool questions are about alternative use of these tools.

Developers ask questions about alternative use of race tools for purposes such as profiling and performance
monitoring of their concurrent software.

About 1 in 11 race tool questions are
about alternative use of these tools.

§ IMPLICATIONS

The results of our study can not only help concurrency developers
and their practice but also the research and education of concurrent
software development to better decide where to focus their efforts.
Members of these communities could use tradeoffs between our concurrency and tool usage
topics as one of several factors they use in their decision making
process. One way to tradeoff a topic against another is
using their popularities, difficulties, sentiments, or the number of their questions.
Obviously, there are many factors that go into tradeoffs that practitioners, researchers,
and educators make to decide where to focus their efforts.
However, we believe our findings can contribute to inform and improve these decisions.

To illustrate, fig-bubble shows the difficulty of our top 10 most popular concurrency topics.
For simplicity, we use the average number of views as the popularity metric and

and the percentage of questions without accepted answers as the difficulty metrics of these topics.

The popularity of topics on the vertical axis increases from bottom to top.
And the difficulty
of topics on the horizontal axis increases from left to right.
The quadrants halve the ranges for the values of the popularity and difficulty metrics.
In fig-bubble, a topic is represented by a circle where the size of the circle is proportional to the
number of questions in the topic, according to fig-topic-question.

Similarly, fig-bubble-senti shows the sentiment of our top 10 most popular concurrency topics.
Again, for simplicitly, we use the percentage of positive sentiment as the metric for the sentiment of topics.
The sentiment of topics on the horizontal axis increases from left to right.

According to Figures <ref> and <ref>, a developer with interest
in concurrency may make a tradeoff between
the popularities, difficulties, and sentiments of concurrency topics to decide to start their learning
from the more popular, less difficult, and more positive task parallelism topic

before the less popular, more difficult, and less positive thread pool topic.
Similarly, a manager of a concurrency development team may

decide to assign a task related to
the less difficult and more positive object-oriented concurrency topic

to a less experienced developer
and a task related to the more difficult and less positive thread pool topic

to a more experienced developer <cit.>.

According to fig-bubble, a developer with interest in concurrency may decide to start their learning

on the more popular and less difficult task parallelism topic in the concurrency models category before
the less popular and more difficult

database management systems topic in the persistence category.

According to Figures <ref> and <ref>, an experienced concurrency researcher
may make a tradeoffs between  difficulties, popularities, and sentiments of concurrency topics to
decide to focus their research on the more difficult, less popular, and less positive process life cycle management
rather than the less difficult, more popular, and more positive task parallelism
in the hope of making more contributions in a less crowded area.
Conversely, a researcher looking to transition anew to the concurrency research may decide to start their research
from the more popular, less
difficult, and more positive thread safety topic.

According to fig-bubble, an experienced concurrency researcher
may decide to focus their research
on the more difficult and less popular thread pool topic
rather than the less difficult and more popular thread life cycle management in the hope of making more contributions in a less crowded area.
Conversely, a researcher looking to transition anew to the concurrency research may decide to start their research on the more popular and less
difficult thread safety topic.

According to Figures <ref> and <ref>, a concurrency educator may decide to teach the material related to the less difficult, more
popular, and more positive thread safety topic before the more difficult, less popular, and less positive thread pool,
accounting for  the dependencies between these topics. The educator may also decide to prepare more material and spend more time in both the class
and lab on the more difficult and less positive thread scheduling topic  than the less difficult and more positive thread safety.
This decision is further supported by the observation that

there are more questions about thread scheduling

than thread safety.
In addition, according to fig-tool-usage,
the educator teaching about data race tools may decide to spend more time

on root cause identification topic with more number of questions

configuration and execution topic for these data race tools with less questions.

Concurrency practitioners, researchers, and educators can use our findings to make decisions about where to focus their effors.

Other tradeoffs
Similarly, fig-bubble-senti shows the sentiment of our top 10 most popular concurrency topics.
For simplicitly, we use percentage of positive sentiment as the measure for sentiment of topics.
The sentiment of topics on the horizontal axis increases from left to right.

In addition to

topic popularity and difficulty, practitioners, researchers, and educators can use
popularity and sentiment as well as difficulty and sentiment to tradeoff topics in their decision making process.
fig-bubble-senti shows the tradeoff for our top 10 most popular topics using their popularity and positive sentiment.

§ THREATS TO VALIDITY

Our use of concurrency tags to identify concurrency questions and answers in is

a threat to the validity of our study.
This is because concurrency tags may not be able to identify the complete set of questions and answers related to concurrency.
To minimize this threat, we use well-known techniques used by previous work <cit.> in
developing our concurrency tags and perform solid experiments with a broad range
of tag relevance and significance thresholds for $\sig$ and $\rela$.
Similarly, our use of race tool keywords to identify race tool questions is a threat.
To minimize this threat, we include industrial race tools that are in use by companies like Google <cit.> and academic race tools
and techniques surveyed by previous work <cit.>.

Our use of as the sole dataset

another threat.

This is because questions and answers may not be  representative of interests, difficulties, sentiments, and race tool usages
of concurrency developers.
However, the large number of participant developers and questions and answers in along with
its wide-spread popularity among developers could mitigate this risk.
Also, unlike some previous work that only use the title of questions in their study
<cit.>, we use both the title and the body of the questions as well as their
accepted answers to mitigate this risk.

Our metrics used to measure the popularity, difficulty, and sentiment of topics is another threat.
This is because other factors, such as the

time and day of a question,

length of the title, body, and code snippets <cit.>,
of the question can affect its popularity <cit.>, difficulty <cit.>, and sentiment <cit.>.
In fact, Wang <cit.> study 46 factors that can affect the time to answer for a question.

To minimize this threat, we use well-known metrics and tools used by previous work to measure

popularity <cit.>, difficulty <cit.>,
and sentiment <cit.>.

Our manual labeling of topics is

another threat.

To minimize this threat, we use a well-known approach used by previous work <cit.> to label topics
using their top 10 words and 15 random questions.
Determining an optimal value for $K$ when modeling topics is another threat.
To minimize this threat, we use a well-known approach used by  previous work <cit.> to find
a reasonable value for $K$ using experiments with a broad range of values for $K$.
It is well-known that determining an optimal value for $K$ is difficult <cit.>.

Parsing dataset, labeling topics from textual contents of questions and answers,

and reduction of words to their
bases is another threat.
To minimize this threat,

we use well-known tools used by previous work.
We parse posts using Python elementTree XML API <cit.>, model topics using <cit.>, and
reduce words

using the Porter stemming algorithm <cit.>.

§ RELATED WORK

Previous works that are closer to our work study software knowledge repositories, such as ,
to understand
interest <cit.>, difficulty <cit.>, and
sentiment <cit.> of developers.

§.§ Concurrency

Closest to our work is the work of Pinto <cit.> that uses the 250 most popular concurrency questions on to study difficulties that developers face when writing concurrent programs. They categorize these difficulties into a set
of themes

including theoretical and practical concepts, threading, and first steps themes.

In other previous work, Pinto <cit.> analyze the code for 2,227 projects to understand the usage of Java's concurrent programming
constructs and libraries and the evolution of their usage.
Lin and Dig <cit.> study a corpus of 611 widely used Android apps to understand how developers use Android constructs for
asynchronous concurrency. Blom <cit.> study the usage of |java.util.concurrent| library in Qualitas corpus.
Godefroid and Nagappan <cit.> survey 684 developers to study the spread and popularity of concurrency platforms and models
at Microsoft.

In contrast, in this work, we develop a set of concurrency tags to extract concurrency questions and answers from ;
group these posts into concurrency topics, categories, and a topic hierarchy;
and analyze popularity, difficulty, and sentiment of these concurrency topics
and their correlations. We also develop a set of race tool keywords to extract
concurrency questions about data race tools and techniques; and group these
questions into race tool topics. Finally, we discuss the implications of our findings for the
practice, research, and education of concurrent software development,
investigate the relation of our findings with the findings of previous work and
present a sample set of questions for each of our concurrency topics and categories.

§.§ Non-concurrency

Rosen and Shihab <cit.> use LDA to model mobile development topics on .
They study popularity and difficulty of their mobile topics and categorize
developers' questions based on platforms for mobile development and type of questions
that developers ask (why, what, and how).
Yang <cit.> use LDA tuned with a genetic algorithm to model security topics on and
manually organize their topics into 5 categories. They study popularity and difficulty of their security topics.
Bajaj <cit.> use LDA to model client-side web development topics using and study

interest of developers in these topics and challenges they face when working with these topics.
Barua <cit.> use LDA to model general topics on .
They study relations of questions and answers of these topics and evolution of
developers' interest in these topics both in general and for specific technologies.

Gyöngyi <cit.> and Adamic <cit.> study
Yahoo!Answers posts to determine developers' interests in a set of predefined categories.
Hindle <cit.> use LDA to model topics related to development tasks
from commit messages of a standalone
software project and study evolution of developers' interest in these topics.

Treude <cit.> and Allamanis and Sutton <cit.> study
questions and answers to infer types of questions that developers ask and determine their difficulties with
these question types.
Bajracharya and Lopes <cit.> study logs of Koders, a code search
engine, to learn about general topic of interest to developers in code search.

Guzman <cit.> study the sentiment of commit
logs and its relation
with programming languages, team distribution, and approvals
in 90 projects.
They find that commit logs for Java projects tend to be more negative, projects with more
distributed teams tend to have more positive commit logs, and Monday commit logs
are more negative.
Similarly, Sinha <cit.> study the sentiment of
logs in
28K projects and
find that a majority of commit logs are neutral,
Tuesday commit logs
are more negative, and a strong correlation exists between sentiment of commit logs
and the average number of files changed in the commits.

Ortu <cit.> study the sentiment, emotion, and politeness

of issue comments and their relations with the time to fix the
issues in  506K issue comments of 14 projects in the Apache issue tracking
system (JIRA). They find that issues with positive sentiment tend to take less
time to be fixed and there is a weak relation between sentiment, emotion, and
politeness. Souza and Silva <cit.> study the
sentiment of commit logs in 1,262 projects and its relation
with builds performed by Travis CI continuous integration server.
They find that commit logs with negative sentiment are more likely to result in broken builds.
Garcia <cit.> study the relation between emotion and activity of contributors in the open source project GENTOO
using its bug tracking issues and mail archives. They find that contributors with strong positive or negative emotions are more likely
to leave the project.
Bazelli <cit.> study the relation between the sentiment of developers' answers on and their reputation and find
that top reputed authors express less negative emotions in their answers.
Muriga <cit.> study whether software artifacts such as issue reports
carry emotional information and find that issue reports include emotional information about design choices,
maintenance activity, and colleagues.

In contrast, in this work, we develop a set of concurrency tags to extract concurrency questions and answers from ;
group these posts into concurrency topics, categories, and a topic hierarchy;
and analyze popularity, difficulty, and sentiment of these concurrency topics
and their correlations. We also develop a set of race tool keywords to extract
concurrency questions about data race tools and techniques; and group these
questions into race tool topics. Finally, we discuss the implications of our findings for the
practice, research, and education of concurrent software development,
investigate the relation of our findings with the findings of previous work and
present a sample set of questions for each of our concurrency topics and categories.

§ CONCLUSIONS

In this work, we conduct a large-scale study on the entirety of to
understand interests, difficulties, sentiments, and tool usages of concurrency
To conduct this study, we develop a set of concurrency tags to
extract concurrency questions and answers from ;
group these questions and answers into concurrency topics, categories, and a
topic hierarchy;
analyze popularities, difficulties, and sentiments of these concurrency topics
and their correlations;
develop a set of tool keywords to extract concurrency questions
about data race tools
and group these questions into race tool topics; and
finally  discuss the implications of our findings for the practice, research,
and education of concurrent software development, investigate the relation of our findings
with the findings of the previous work, and present a set of examples questions that developers
ask for each of our concurrency and tool topics.

In this work, we conduct a large-scale
study on  the entirety of to understand
interest, difficulty, sentiment, and tool usage of concurrency developers.

We develop a set of concurrency tags to extract concurrency questions and answers from ;
group these posts into concurrency topics, categories, and a topic hierarchy;
and analyze popularity, difficulty, and sentiment of these concurrency topics
and their correlations. We also develop a set of race tool keywords to extract
concurrency questions about data race tools and techniques; and group these
questions into race tool topics.
Finally, we discuss the implications of our findings for the
practice, research, and education of concurrent software development,
investigate the relation of our findings with the findings of previous work and
present a set of questions for each of our concurrency topics and categories.

§ ACKNOWLEDGEMENTS

Bagherzadeh, Ahmed, and Sripathi were supported in part by the Department of Computer Science and Engineering and the Research Office at
Oakland University.
Khatchadourian was supported by PSC-CUNY Awards #617930049 and
#638010051, jointly funded by The Professional Staff Congress and The City University of New York.
We would also like to thank Nicholas Fireman for his help.


# Algebraic delocalization for the Schrödinger equation on large tori

Henrik Ueberschär  Sorbonne Université, Université Paris Cité, CNRS, IMJ-PRG,
F-75006 Paris, France<EMAIL_ADDRESS>
###### Abstract.

Let ${\mathcal{L}}$ be a fixed $d$-dimensional lattice. We study the
localization properties of solutions of the stationary Schrödinger equation
with a positive $L^{\infty}$ potential on tori
${\mathbb{R}}^{d}/L{\mathcal{L}}$ in the limit, as $L\to\infty$, for dimension
$d\leq 3$.

We show that the probability measures associated with $L^{2}$-normalized
solutions, with eigenvalue $E$ near the bottom of the spectrum, satisfy an
algebraic delocalization theorem which states that these probability measures
cannot be localized inside a ball of radius $r=o(E^{-1/4+\epsilon})$, unless
localization occurs with a sufficiently slow algebraic decay.

In particular, we apply our result to Schrödinger operators modeling
disordered systems, such as the $d$-dimensional continuous Anderson-Bernoulli
model, where almost sure exponential localization of eigenfunctions, in the
limit as $E\to 0$, was proved by Bourgain-Kenig in dimension $d\geq 2$, and
show that our theorem implies an algebraic blow-up of localization length in
this limit.

##  1\. Introduction

We are motivated by the study of the localization properties of eigenfunctions
of Schrödinger operators which describe disordered systems. For instance,
Bourgain-Kenig [3] considered the Anderson-Bernoulli model on
${\mathbb{R}}^{d}$, $d\geq 2$, (the case $d=1$ had previously been treated in
[4])

(1.1)
$H_{AB}=-\Delta+\sum_{\xi\in{\mathbb{Z}}^{d}}\alpha_{\xi}\varphi(\cdot-\xi)$

where $\varphi\in C^{\infty}_{c}({\mathbb{R}}^{d})$, $0\leq\varphi\leq 1$,
$\operatorname{supp}\varphi\subset B(0,1/10)$ with i.i.d. Bernoulli couplings
$\alpha_{\xi}\in\\{0,1\\}$. One notes that $\inf\sigma(H_{\alpha})=0$ almost
surely.

Bourgain-Kenig found that solutions of the stationary Schrödinger equation
$H_{AB}\Psi=E\Psi$ were almost surely exponentially localized in the limit
$E\to 0$, therefore proving Anderson localization [2] in the spectral sense. A
natural way to study this phenomenon is to consider the operator restricted to
a box $[0,L]^{d}\subset{\mathbb{R}}^{d}$, $d\geq 2$, with appropriate boundary
conditions and investigate the localization properties of the eigenfunctions
in the thermodynamic limit, as $L\to+\infty$.

In this article, instead of considering random operators we will study
deterministic operators for any given configuration of scatterer positions and
coupling constants. For example, in the case of the continuous Anderson-
Bernoulli model, fix a function $\alpha:{\mathbb{Z}}^{d}\to\\{0,1\\}$ and
associate with it the Schrödinger operator

(1.2)
$H_{\alpha}=-\Delta+\sum_{\xi\in{\mathbb{Z}}^{d}}\alpha(\xi)\varphi(\cdot-\xi).$

We will then study the localization properties of the eigenfunctions of
$H_{\alpha}$ for any given Boolean function $\alpha$ on the lattice
${\mathbb{Z}}^{d}$.

A key application of the algebraic delocalization theorem which is proved in
this article will be the divergence of the localization length associated with
an eigenfunction of $H_{\alpha}$, as $E\to 0$. We stress for the case $d=2$
that this type of delocalization does not constitute a contradiction to the
scaling theory of localization [1]: in fact, a similar type of divergence of
localization length has been observed in the physics literature for certain
models [5, 6]. In this context, the authors found multifractal properties of
the eigenfunctions, but no full transition to a regime with extended states.

##  2\. Statement of results

We consider Schrödinger operators on boxes with periodic boundary conditions
(our method should work for other self-adjoint b.c.s and more general
domains). We study $L^{\infty}$ potentials which remain bounded in the
thermodynamic limit, with $\inf V=0$ and $\sup V=V_{1}>0$, a condition which
is, in particular, satisfied by the Anderson-Bernoulli operator (1.2) for any
configuration of coupling constants.

###  2.1. Algebraic delocalization

Let $d\leq 3$ and ${\mathbb{T}}^{d}_{L}={\mathbb{R}}^{d}/L{\mathcal{L}}_{0}$,
where $L>0$ is a large parameter, and
${\mathcal{L}}_{0}={\mathbb{Z}}(1,0,\cdots,0)\oplus{\mathbb{Z}}(0,\gamma_{1},\cdots,0)\oplus{\mathbb{Z}}(0,\cdots,0,\gamma_{d-1})$,
$\gamma_{1},\cdots,\gamma_{d-1}\geq 1$. Let $V\in
L^{\infty}({\mathbb{T}}^{d}_{L})$ with $V\geq 0$ and $\inf V=0$. We consider a
solution of the Schrödinger equation

(2.1)
$(-\Delta+V)\Psi=E\Psi,\quad\|\Psi\|_{L^{2}({\mathbb{T}}^{d}_{L})}=1,\quad
0<E<1.$

We show that the $L^{2}$-density $d\mu_{\Psi}=|\Psi|^{2}d\mu$ associated with
a solution $\Psi$ of (2.1) can only vary subject to certain algebraic
constraints. In particular we choose scales $\ell\asymp E^{-1/4+\eta(1-d/4)}$,
$\eta\in(0,1/(4-d))$, and $r=\ell E^{-\eta}$. We show that for any
$x_{0}\in{\mathbb{T}}^{d}_{L}$ the ball $B(x_{0},\ell)$ contains either less
than half of the $L^{2}$-mass of $\Psi$: $\mu_{\Psi}(B(x_{0},\ell))<1/2$, or
the larger ball $B(x_{0},r)$ contains less than $1-E$ of the $L^{2}$-mass of
$\Psi$: $\mu_{\Psi}(B(x_{0},r))<1-E$.

######  Theorem 2.1.

There exist absolute constants $c_{1},c_{2}>0$ such that the following holds.
Let $\eta\in(0,1/(d-4))$. Denote

$c_{V}=c_{1}(1+\|V\|_{\infty}^{1/2})^{-1/2}.$

Let $\Psi$ be a solution of $\eqref{Sch}$ with eigenvalue

(2.2)
$E\in[(2c_{V}/L)^{4/(1+d\eta)},\min(c_{V}^{4/(1+d\eta)},c_{2}^{2/d\eta})],$

where we assume that $L$ is sufficiently large.

Then, we have for any $x_{0}\in{\mathbb{T}}^{d}_{L}$:111Note that (2.2)
ensures that $1\leq c_{V}E^{-1/4-d\eta/4}\leq\tfrac{1}{2}L$

(2.3) $\int_{B(x_{0},c_{V}E^{-1/4+\eta(1-d/4)})}|\Psi|^{2}d\mu<\frac{1}{2}$

or

(2.4) $\int_{{\mathbb{T}}^{d}_{L}\setminus
B(x_{0},c_{V}E^{-1/4-d\eta/4})}|\Psi|^{2}d\mu>E.$

###  2.2. Blow-up of localization length

We will illustrate the meaning of Theorem 2.1 by demonstrating that, if we
suppose that a solution of the Schrödinger equation (2.1) is localized with
respect to a localization center, then our theorem implies that the
localization length admits an algebraic singularity, as $E\to 0$, unless the
decay of the localization is no faster than algebraic with exponent $d-4$.

Let $\delta:[1,+\infty)\mapsto[0,\tfrac{1}{2}]$ be a continuous, strictly
decreasing function. We say that $\Psi$ is localized with respect to $x_{0}$
with localization length $\ell_{loc}$ and decay
$\delta:[1,+\infty)\mapsto[0,\tfrac{1}{2}]$, if we have for any
$r\geq\ell_{loc}$

(2.5) $\int_{{\mathbb{T}}^{d}_{L}\setminus
B(x_{0},r)}|\Psi|^{2}d\mu\leq\delta\left(\frac{r}{\ell_{loc}}\right).$

One may now use the result above to deduce lower bounds for the localization
length.

Take $\ell_{1}=c_{V}E^{-1/4+d\eta/4}$, where
$c_{V}=c_{1}(1+\|V\|_{L^{\infty}}^{1/2})^{-1/2}$. Suppose that
$\ell_{1}\geq\ell_{loc}$ (if $\ell_{1}<\ell_{loc}$, then we have our lower
bound). Using the result above we know that for each
$x_{0}\in{\mathbb{T}}^{d}_{L}$ either (2.3) or (2.4) must hold. We will show
that both inequalities (2.3) and (2.4) imply a blow-up of localization length,
as $E\to 0$.

Inequality (2.3) together with the localization hypothesis implies

$\delta\left(\frac{\ell_{1}}{\ell_{loc}}\right)\geq\int_{{\mathbb{T}}^{d}_{L}\setminus
B(x_{0},\ell_{1})}|\Psi|^{2}d\mu>\frac{1}{2}$

which is a contradiction, because
$\delta(\ell_{1}/\ell_{loc})\leq\tfrac{1}{2}$. So, we have the lower bound

$\ell_{loc}>\ell_{1}=c_{V}E^{-1/4+\eta(1-d/4)}.$

Let us suppose that inequality (2.4) holds and deduce a blow-up of
localization length in this case. Denote $\ell_{2}=\ell_{1}E^{-\eta}$. We have
$\ell_{2}\geq\ell_{1}\geq\ell_{loc}$ by our assumption
$\ell_{1}\geq\ell_{loc}$. Therefore,

$\delta\left(\frac{\ell_{2}}{\ell_{loc}}\right)\geq\int_{{\mathbb{T}}^{d}_{L}\setminus
B(x_{0},\ell_{1})}|\Psi|^{2}d\mu>E.$

Because $\delta$ is strictly decreasing, we have

$\frac{\ell_{2}}{\ell_{loc}}<\delta^{-1}(E)$

which yields the lower bound

$\ell_{loc}>\frac{\ell_{2}}{\delta^{-1}(E)}=c_{V}E^{-1/4-d\eta/4}/\delta^{-1}(E).$

In conclusion, we must have the following lower bound for the localization
length

(2.6)
$\ell_{loc}>c_{V}E^{-1/4+\eta(1-d/4)}\min\left(1,\frac{E^{-\eta}}{\delta^{-1}(E)}\right)$

####  2.2.1. Delocalization for exponential decay

In the case of an exponential decay with respect to a localization center
$x_{0}$, we have for $C,\beta>0$

$\int_{{\mathbb{T}}^{d}_{L}\setminus B(x_{0},r)}|\Psi|^{2}d\mu\leq Ce^{-\beta
r}=\delta\left(\frac{r}{\ell_{loc}}\right)$

with

$\delta(r)=Ce^{-\log(2C)r},\quad\ell_{loc}=\frac{\log(2C)}{\beta}.$

Since $\delta^{-1}(E)=-\log(E/C)/\log(2C)$, we obtain from (2.6) the lower
bound (recall $\eta\in(0,1/(4-d))$)

$\ell_{loc}>c_{V}E^{-1/4+\eta(1-d/4)}\min\left(1,\log(2C)\frac{E^{-\eta}}{\log(C/E)}\right)$

####  2.2.2. Delocalization for sufficiently fast algebraic decay.

In particular, we see that for any sufficiently fast algebraic decay we may
deduce $\ell_{loc}\nearrow+\infty$ as $E\to 0^{+}$. To see this take
$\delta(r)=Cr^{-\alpha}$, which gives

$\ell_{loc}>c_{V}E^{-1/4+\eta(1-d/4)}\min\left(1,C^{-1/\alpha}E^{-\eta+1/\alpha}\right).$

So, for $\alpha\geq 1/\eta$, we have

$\ell_{loc}\lesssim E^{-1/4+\eta(1-d/4)},$

because for small $E$, $E^{-\eta+1/\alpha}$ is large. We then have a blow-up,
since $\eta\in(0,1/(4-d))$.

Moreover, if $\alpha<1/\eta$, then $E^{-\eta+1/\alpha}$ is small if $E\to 0$.
So, the lower bound is of order

$\ell_{loc}\lesssim E^{-1/4-d\eta/4+1/\alpha},$

and we have a blow-up provided $1/\alpha<1/4+d\eta/4$. This yields the general
condition $\alpha>4/(1+d\eta)$ to ensure a blow-up of localization length.
Since $\eta\in(0,1/(4-d))$, we can rule out any decay faster than exponent
$4-d$.

###  2.3. Generalization to spectral projectors

In the context of Anderson localization it is natural to study the
localization properties of all eigenfunctions in a given spectral window
${\mathcal{I}}=[E,2E]$, $0<E<1$. Let $h:{\mathbb{R}}\to{\mathbb{R}}$ be a
continuous, compactly supported function with
$\operatorname{supp}h\subset{\mathcal{I}}$.

We introduce

$\Pi_{h}(x,y)=\sum_{\lambda}h(\lambda)\Psi_{\lambda}(x)\overline{\Psi_{\lambda}}(y).$

We note that, while individual eigenfunctions are expected to be exponentially
localized with respect to a localization center, these centers may be
different for each eigenfunction. Therefore one considers a spectral projector
$\Pi_{h}(x,y)$ which ought to satisfy an exponential decay with respect to the
distance $|x-y|$.

Let us fix $x_{0}\in{\mathbb{T}}^{d}_{L}$ and let
$F=\Pi_{h}(\cdot,x_{0})/\|\Pi_{h}(\cdot,x_{0})\|_{L^{2}({\mathbb{T}}^{d}_{L})}$.
Let $\mu_{h}$ be the probability measure associated with the probability
density $d\mu_{h}=|F|^{2}d\mu$. We have the following algebraic delocalization
theorem which is a generalization of Theorem 2.1.

######  Theorem 2.2.

Assume that $E$ satisifies the conditions of Theorem 2.1. Let
$B_{\ell}\subset{\mathbb{T}}^{d}_{L}$ be any ball of radius
$\ell=c_{V}E^{-1/4+\eta(1-d/4)}$, and $B_{r}\subset{\mathbb{T}}^{d}_{L}$ be a
ball with the same center and radius $r=\ell E^{-\eta}$. We have either
$\mu_{h}(B_{\ell})<\tfrac{1}{2}$ or $\mu_{h}(B_{r})<1-E$.

Arguing as in the previous section one may now deduce a blow-up of
localization length for any decay faster than exponent $d-4$.

##  3\. Proof of Theorem 2.1

We argue by contradiction. Recall
$\ell=c_{1}E^{-1/4+\eta(1-d/4)}(1+\|V\|_{L^{\infty}}^{1/2})^{-1/2}$. Let us
suppose there exists $x_{0}\in{\mathbb{T}}^{d}_{L}$ such that

(3.1) $\int_{B(x_{0},\ell)}|\Psi|^{2}d\mu\geq\frac{1}{2}$

and

(3.2) $\int_{{\mathbb{T}}^{d}_{L}\setminus B(x_{0},\ell
E^{-\eta})}|\Psi|^{2}d\mu\leq E.$

###  3.1. A variation bound

Let $r=\ell E^{-\eta}$ for $\eta\in(0,1/(4-d))$. We recall that our assumption
(2.2) implies $1\leq r\leq\tfrac{1}{2}L$. Let
$\Lambda_{2r}\subset{\mathbb{T}}^{d}_{L}$ be a box of side length $2r$
centered on $x_{0}$ inside the torus such that
$B(x_{0},r)\subset\Lambda_{2r}$. Let $\chi\in
C^{\infty}({\mathbb{T}}^{d}_{L})$ be a smoothed indicator in the sense that
$\Lambda_{2r}\subset\operatorname{supp}\chi\subset\Lambda_{2r+1}$, and
$\chi|_{\Lambda_{2r}}=1$. Moreover we may choose $\chi$ in such a way that
$\sup|\nabla\chi|\leq k_{1}$ and $\sup|\Delta\chi|\leq k_{2}$ for absolute
constants $k_{1},k_{2}$.

Let $x_{1},x_{2}\in\Lambda_{2r}$. Let $r^{\prime}=2r+1$. We recall that the
kernel $G_{\lambda}$ of the resolvent $(-\Delta-\lambda)^{-1}$ on
$\Lambda_{r^{\prime}}$ can be expanded with respect to the o. n. b. of
exponentials $e(\xi\cdot x/r^{\prime})r^{\prime-d/2}$,
$\xi\in{\mathbb{Z}}^{d}$, as

$G_{\lambda}(x,y)=-\frac{1}{r^{\prime
d}\lambda}+\sum_{\xi\in{\mathbb{Z}}^{2}\setminus\\{0\\}}\frac{1}{4\pi^{2}|\xi/r^{\prime}|^{2}-\lambda}\frac{e(\xi\cdot(x-y)/r^{\prime})}{r^{\prime
d}},$

where $\lambda\notin\sigma(-\Delta)$ and we denote $e(\tau)=e^{2\pi i\tau}$.

We then have

$G_{\lambda}(x,x_{1})-G_{\lambda}(x,x_{2})=\sum_{\xi\in{\mathbb{Z}}^{2}\setminus\\{0\\}}\frac{e(\xi\cdot(-x_{1})/r^{\prime})-e(\xi\cdot(-x_{2})/r^{\prime})}{4\pi^{2}|\xi/r^{\prime}|^{2}-\lambda}\frac{e(\xi\cdot
x/r^{\prime})}{r^{\prime d}}.$

We note that we may pass to the limit $\lambda\to 0$ and obtain an $L^{2}$
function on $\Lambda_{r^{\prime}}$.

Let us define $b\in L^{2}(\Lambda_{r^{\prime}})$ by

$b(x):=\frac{1}{4\pi^{2}}\sum_{\xi\in{\mathbb{Z}}^{2}\setminus\\{0\\}}\frac{e(-\xi\cdot
x_{1}/r^{\prime})-e(-\xi\cdot x_{2}/r^{\prime})}{r^{\prime
d/2}|\xi/r^{\prime}|^{2}}\frac{e(\xi\cdot x/r^{\prime})}{r^{\prime d/2}}$

so that

$-\Delta b=\delta_{x_{1}}-\delta_{x_{2}}.$

Recall $x_{1},x_{2}\in\Lambda_{2r}$. By construction of the smooth cut-off
$\chi$ above, we have $\chi\Psi\in C^{2}(\Lambda_{r^{\prime}})$ and
$\chi\Psi|_{\partial\Lambda_{r^{\prime}}}$=0, which ensures that the cutoff
$\chi\Psi$ satisfies periodic boundary conditions. We have the identity

(3.3) $\Psi(x_{1})-\Psi(x_{2})=\int_{\Lambda_{r^{\prime}}}(-\Delta
b)\,\chi\Psi\,d\mu=\int_{\Lambda_{r^{\prime}}}b\,(-\Delta(\chi\Psi))\,d\mu$

We may now expand

$-\Delta(\chi\Psi)=-\Psi\Delta\chi-2\nabla\chi\cdot\nabla\Psi-\chi\Delta\Psi.$

We estimate the integral term by term. We start with the third term

(3.4)
$\int_{\Lambda_{r^{\prime}}}b\,\chi\,(-\Delta\Psi)\,d\mu=E\int_{\Lambda_{r^{\prime}}}b\,\chi\,\Psi\,d\mu-\int_{\Lambda_{r^{\prime}}}b\,\chi\,V\Psi\,d\mu$

where we used $(-\Delta+V)\Psi=E\Psi$.

Moreover, the identity

$0\leq\int_{{\mathbb{T}}^{d}_{L}}|\nabla\Psi|^{2}d\mu=\int_{{\mathbb{T}}^{d}_{L}}-\Delta\Psi\cdot\overline{\Psi}d\mu=\int_{{\mathbb{T}}^{d}_{L}}(E-V)|\Psi|^{2}d\mu$

yields

$\int_{\Lambda_{r^{\prime}}}V|\Psi|^{2}d\mu\leq\int_{{\mathbb{T}}^{d}_{L}}V|\Psi|^{2}d\mu\leq
E,$

where we used $\|\Psi\|_{L^{2}({\mathbb{T}}^{d}_{L})}=1$.

Hence, Cauchy-Schwarz yields

(3.5)
$\begin{split}\Big{|}\int_{\Lambda_{r^{\prime}}}b\,\chi\,V\Psi\,d\mu\Big{|}&\leq\|b\chi\|_{L^{2}(\Lambda_{r^{\prime}})}\|V\|_{L^{\infty}}^{1/2}\left(\int_{{\mathbb{T}}^{d}_{L}}V|\Psi|^{2}\right)^{1/2}\\\
&\leq\|b\|_{L^{2}(\Lambda_{r^{\prime}})}\|V\|_{L^{\infty}}^{1/2}E^{1/2}\end{split}$

(note
$\|b\chi\|_{L^{2}(\Lambda_{r^{\prime}})}\leq\|b\|_{L^{2}(\Lambda_{r^{\prime}})}$)
and

(3.6)
$\begin{split}\|b\|_{L^{2}(\Lambda_{r^{\prime}})}\leq\frac{1}{2\pi^{2}}\left(\sum_{\xi\in{\mathbb{Z}}^{2}\setminus\\{0\\}}\frac{1}{r^{\prime
d}|\xi/r^{\prime}|^{4}}\right)^{1/2}=\frac{r^{\prime(4-d)/2}L_{d}(2)^{1/2}}{2\pi^{2}}\end{split}$

where we denote the Dirichlet series

$L_{d}(s)=\sum_{n=1}^{\infty}r_{d}(n)n^{-s}$

associated with $r_{d}(n)$, the number of ways the integer $n$ can be
represented as a number of $d$ squares. Note that the series converges for
$s=2$, since $d\leq 3$.

Moreover,

$E\Big{|}\int_{\Lambda_{r^{\prime}}}b\chi\Psi d\mu\Big{|}\leq
E\|b\chi\|_{L^{2}(\Lambda_{r^{\prime}})}\leq\frac{Er^{\prime(d-4)/2}L_{d}(2)^{1/2}}{2\pi^{2}}$

where we used $\|\Psi\|_{L^{2}({\mathbb{T}}^{d}_{L})}=1$ and
$\Lambda_{r^{\prime}}\subset{\mathbb{T}}^{d}_{L}$.

Let us continue with the second term. We have

(3.7) $\Big{|}\int_{\Lambda_{r^{\prime}}}b\nabla\chi\cdot\nabla\Psi
d\mu\Big{|}\leq\|b\|_{L^{2}(\Lambda_{r^{\prime}})}\|\nabla\chi\cdot\nabla\Psi\|_{L^{2}(\Lambda_{r^{\prime}})}$

and

$\displaystyle\|\nabla\chi\cdot\nabla\Psi\|_{L^{2}(\Lambda_{r^{\prime}})}\leq\left(\int_{\Lambda_{r^{\prime}}}|\nabla\chi|^{2}|\nabla\Psi|^{2}d\mu\right)^{1/2}$
$\displaystyle\leq k_{1}\||\nabla\Psi|\|_{L^{2}({\mathbb{T}}^{d}_{L})}$

where we recall $\sup|\nabla\chi|\leq k_{1}$, and, as we saw above,

$\||\nabla\Psi|\|_{L^{2}({\mathbb{T}}^{d}_{L})}^{2}=\int_{{\mathbb{T}}^{d}_{L}}(E-V)|\Psi|^{2}d\mu\leq
E,$

where we used $\|\Psi\|_{L^{2}({\mathbb{T}}^{d}_{L})}=1$ and $V\geq 0$.

So, in summary, we bound the second term as follows:

$\Big{|}\int_{\Lambda_{r^{\prime}}}b\nabla\chi\cdot\nabla\Psi d\mu\Big{|}\leq
k_{1}\frac{L_{d}(2)^{1/2}}{2\pi^{2}}r^{\prime(4-d)/2}E^{1/2}.$

For the first term, we use (3.2):

(3.8)
$\begin{split}\Big{|}\int_{\Lambda_{r^{\prime}}}b\,\Psi\,\Delta\chi\,d\mu\Big{|}\leq&\|b\|_{L^{2}(\Lambda_{r^{\prime}})}\sup|\Delta\chi|\left(\int_{\operatorname{supp}(\Delta\chi)}|\Psi|^{2}d\mu\right)^{1/2}\\\
\leq&k_{2}\frac{L_{d}(2)^{1/2}}{2\pi^{2}}r^{\prime(d-4)/2}E^{1/2}\end{split}$

where we recall $\sup|\Delta\chi|\leq k_{2}$, as well as
$\|b\|_{L^{2}(\Lambda_{r^{\prime}})}\leq
r^{\prime(4-d)/2}L_{D}(2)^{1/2}/2\pi^{2}$.

In the estimate of the integral over $\operatorname{supp}(\Delta\chi)$, we
note that by construction of the cutoff function $\chi$ we have
$\operatorname{supp}(\Delta\chi)\subset\Lambda_{r^{\prime}}\setminus\Lambda_{2r}$
(recall $r^{\prime}=2r+1)$ and, therefore,

$\operatorname{supp}(\Delta\chi)\subset{\mathbb{T}}^{d}_{L}\setminus\Lambda_{2r}\subset{\mathbb{T}}^{d}_{L}\setminus
B(x_{0},r)$

and, thus, using (3.2) (recall $r=\ell E^{-\eta}$), we obtain

$\int_{\operatorname{supp}(\Delta\chi)}|\Psi|^{2}d\mu\leq\int_{{\mathbb{T}}^{d}_{L}\setminus
B(x_{0},r)}|\Psi|^{2}d\mu\leq E.$

Combining all of the above estimates, we obtain

(3.9) $\Big{|}\Psi(x_{1})-\Psi(x_{2})\Big{|}\leq
cr^{(4-d)/2}(1+\|V\|_{L^{\infty}}^{1/2})E^{1/2}$

where $c>0$ denotes an absolute constant and $r^{\prime}=2r+1\leq 3r$, as
$r\geq 1$.

###  3.2. Proof

In order to prove the result we will first of all show that our assumption

$\int_{B(x_{0},\ell)}|\Psi|^{2}d\mu\geq\frac{1}{2}$

implies that there exists $x^{\prime}\in B(x_{0},\ell)$ s. t.
$|\Psi(x^{\prime})|\geq\sqrt{\frac{1}{2\pi}}\ell^{-d/2}$.

To see this, we argue by contradiction. Suppose we have
$|\Psi(x)|<\sqrt{\frac{1}{2\pi}}\ell^{-d/2}$ for all $x\in B$. Then,

$\int_{B}|\Psi|^{2}d\mu<\frac{1}{2\pi}\ell^{-d}\operatorname{vol}(B)=\frac{1}{2}.$

For any $x\in\Lambda_{2r}$ we have

(3.10)
$\begin{split}|\Psi(x)|&\geq|\Psi(x^{\prime})|-|\Psi(x)-\Psi(x^{\prime})|\\\
&\geq\frac{1}{\sqrt{2\pi}}\ell^{-d/2}-c(1+\|V\|_{L^{\infty}}^{1/2})r^{(4-d)/2}E^{1/2}.\end{split}$

In order to have a lower bound of order $\ell^{-d/2}$, we then need

$c^{\prime}\ell^{-d/2}\geq(1+\|V\|_{L^{\infty}}^{1/2})r^{(4-d)/2}E^{1/2}=(1+\|V\|_{L^{\infty}}^{1/2})\ell^{(4-d)/2}E^{1/2-\eta(4-d)/2}$

for some absolute constant $c^{\prime}>0$, which, in turn, is equivalent to

$\ell\leq\left(\frac{c^{\prime}}{1+\|V\|_{L^{\infty}}^{1/2}}\right)^{1/2}E^{-1/4+\eta(1-d/4)}$

and we recall that this holds with $c_{1}=c^{\prime 1/2}$.

Then we have for any $x\in\Lambda_{2r}$

$|\Psi(x)|\geq c^{\prime\prime}\ell^{-d/2},$

for an absolute constant $c^{\prime\prime}>0$. This then yields

$\int_{\Lambda_{2r}}|\Psi(x)|^{2}d\mu\geq c^{\prime\prime
2}\frac{(2r)^{d}}{\ell^{d}}=2^{d}c^{\prime\prime 2}E^{-\eta d}$

and, thus, for an absolute constant $0<c_{2}<c^{\prime\prime}$ we have $E\leq
c_{2}^{2/d\eta}<(2c^{\prime\prime 2/d})^{1/\eta}$ and we arrive at a
contradiction to the normalization $\|\Psi\|_{L^{2}({\mathbb{T}}^{d}_{L})}=1$.

##  4\. Proof of Theorem 2.2

For given $x_{0}\in{\mathbb{T}}^{d}_{L}$, we introduce

$F=\frac{\sum_{\lambda\in[E,2E]}h(\lambda)\overline{\Psi_{\lambda}}(x_{0})\Psi_{\lambda}}{(\sum_{\lambda\in[E,2E]}|\Psi_{\lambda}(x_{0})|^{2})^{1/2}}.$

We sketch the argument which is very similar to the one above for individual
eigenfunctions. In particular, we have $-\Delta F=\tilde{F}-VF$, where

$\tilde{F}=\frac{\sum_{\lambda\in[E,2E]}\lambda
h(\lambda)\overline{\Psi_{\lambda}}(x_{0})\Psi_{\lambda}}{(\sum_{\lambda\in[E,2E]}|\Psi_{\lambda}(x_{0})|^{2})^{1/2}}$

and

$\|\tilde{F}\|_{L^{2}}^{2}=\frac{\sum_{\lambda\in[E,2E]}\lambda^{2}h(\lambda)^{2}|\Psi_{\lambda}(x_{0})|^{2}}{\sum_{\lambda\in[E,2E]}|\Psi_{\lambda}(x_{0})|^{2}}\leq
4\|h\|_{L^{\infty}}^{2}E^{2}$

Following the argument above we get for $x_{1},x_{2}\in\Lambda_{2r}$

$|F(x_{1})-F(x_{2})|\leq\Big{|}\int_{{\mathbb{T}}^{d}_{L}}b\,\Delta(\chi
F)\,d\mu\Big{|}$

Let us estimate the integral with the Laplace term

$\int_{{\mathbb{T}}^{d}_{L}}b\,\chi\,\Delta
F\,d\mu=\int_{{\mathbb{T}}^{d}_{L}}b\,\chi\tilde{F}\,d\mu-\int_{{\mathbb{T}}^{d}_{L}}b\,\chi
VF\,d\mu$

For the first term, we find an estimate of the same order as above

$\Big{|}\int_{{\mathbb{T}}^{d}_{L}}b\,\chi\tilde{F}\,d\mu\Big{|}\leq
2E\|b\|_{2}\lesssim r^{\prime(4-d)/2}E^{1/2}.$

For the second term, we have

$\Big{|}\int_{{\mathbb{T}}^{d}_{L}}b\,\chi
VF\,d\mu\Big{|}\leq\|b\|_{L^{2}(\Lambda_{r^{\prime}})}\|V\|_{L^{\infty}}\left(\int_{{\mathbb{T}}^{d}_{L}}V|F|^{2}d\mu\right)^{1/2}$

and

$0\leq\int_{{\mathbb{T}}^{d}_{L}}|\nabla
F|^{2}d\mu=\int_{{\mathbb{T}}^{d}_{L}}(-\Delta
F)Fd\mu=\int_{{\mathbb{T}}^{d}_{L}}\tilde{F}Fd\mu-\int_{{\mathbb{T}}^{d}_{L}}V|F|^{2}d\mu$

which yields

$\int_{{\mathbb{T}}^{d}_{L}}V|F|^{2}d\mu\leq\int_{{\mathbb{T}}^{d}_{L}}\tilde{F}Fd\mu\leq\|\tilde{F}\|_{2}\|F\|_{2}\leq
2\|h\|_{L^{\infty}}E$

And again, we get an estimate of the same order as above

$\Big{|}\int_{{\mathbb{T}}^{d}_{L}}b\,\chi
VF\,d\mu\Big{|}\lesssim\|V\|_{L^{\infty}}r^{\prime(4-d)/2}E^{1/2}$

.

Moreover, for the gradient term we get the same estimate as above due to

$\int_{{\mathbb{T}}^{d}_{L}}|\nabla
F|^{2}d\mu=\int_{{\mathbb{T}}^{d}_{L}}\tilde{F}Fd\mu-\int_{{\mathbb{T}}^{d}_{L}}V|F|^{2}d\mu\leq\int_{{\mathbb{T}}^{d}_{L}}\tilde{F}Fd\mu\leq
2\|h\|_{L^{\infty}}E.$

## References

  * [1] E. Abrahams, P. W. Anderson, D. C. Licciardello, and T. V. Ramakrishnan, Scaling Theory of Localization: Absence of Quantum Diffusion in Two Dimensions, Phys. Rev. Lett. 42 (1979), 673–676.
  * [2] P. W. Anderson, Absence of Diffusion in Certain Random Lattices, Phys. Rev. 109 (1958), 1492–.
  * [3] J. Bourgain, C. Kenig, On localization in the continuous Anderson-Bernoulli model in higher dimension Invent. Math. 161 (2005), 389–426.
  * [4] D. Damanik, R. Sims, G. Stolz, Localization for one-dimensional, continuum, Bernoulli-Anderson models, Duke Math. J. 114 (2002), no. 1, 59–100.
  * [5] A. Eilmes, R. A. Römer, M. Schreiber, The two-dimensional Anderson model of localization with random hopping, Eur. Phys. J. B 1 (1998), 29–38.
  * [6] A. Eilmes, R. A. Römer, M. Schreiber, Exponents of the localization lengths in the bipartite Anderson model with off-diagonal disorder, Physica B 296 (2001), no. 1-3, 46–51.