Keywords

1 Introduction

Over the last decades, in order to achieve ever increasingly powerful architectures, the processor industry has shifted its manufactures towards multi–core and many–core designs. This trend has become so widely adopted that nowadays such hardware is employed not only for industrial and academic purposes [8], but it is also readily available in desktop machines in school laboratories [2]. Alongside to the electronic improvements, to harness the computational power of these machines it is necessary to design software solutions that exploit the numerous cores with concurrent programs.

There is therefore the need for experienced programmers leveraging this paradigm, as indicated, in particular, by the ACM/IEEE Task Force in the Computer Science Curricula 2013 Report [12]. Academic institutions often introduce concurrent programming in advanced dedicated courses or in conjunction with related topics, e.g. [6, 11, 21], but less commonly in introductory programming modules [3, 13]. As a matter of fact, it is still up to debate when and how to approach the subject, and even more open to debate is the feasibility to cover concurrent programming in the high school curriculum [1, 2, 14, 23]. Students’ difficulties to learn concurrent programming are indeed well known among both high school teachers and university instructors, and are also confirmed by a handful of empirical investigations, such as [2, 10, 14].

According to the Italian Ministerial guidelines, the students opting for a technical specialization in Computer Science are expected to develop parallel and concurrent programming skills by the end of their fourth high school year (grade 12).Footnote 1 Unfortunately, however, there is a lack of empirical evidence to set realistic curricular goals. As pointed out by Brođanac et al. in a recent paper, “[i]n the case of teaching parallel programming before university level, the research appears to be scarce” [2, p. 2].

Within the outlined framework, this work is meant as an initial, exploratory investigation on students’ proficiency and self-confidence when dealing with concurrency and synchronization tasks. More specifically, we are trying to find at least some preliminary answers to the following research questions:

  1. Q1.

    To what extent are students at ease with some basic concepts of concurrent programming?

  2. Q2.

    To what extent does students’ perception of self-confidence correlate with their actual performance in simple concurrent programming tasks?

  3. Q3.

    What are their major difficulties when learning concurrent programming?

In order to address the above questions, we have administered a survey including subjective perception questions as well as four program comprehension tasks involving basic aspects of thread synchronization. A total of 68 students attending the last year (grade 13) in representative high schools of our area were engaged in the survey. The students were introduced to concurrent programming in the previous school year, by different teachers who may have used diversified approaches.

The paper is organized as follows. In Sect. 2 we summarize the background of this work. Section 3 is about the survey structure and the rationale underlying its design. The main findings of our exploratory investigation are then outlined in Sect. 4 and discussed in Sect. 5. Finally, in Sect. 6 we draw some conclusions and mention possible future developments of the present work.

2 Background

At least anecdotally, students’ difficulties with concurrent programming are acknowledged by technical high school Computer Science teachers, as well as by lecturer at the undergraduate and graduate levels. Nevertheless, this subject has hardly been given significant attention in the context of introductory programming. For instance, in their systematic study [17] reviewing over 700 research papers published between 2003 and 2018, Luxton-Reilly and colleagues mention only two contributions addressing parallel or concurrent programming.

In the following two subsections we will mention a selection of works specifically focused on the topic, respectively at the tertiary and secondary instruction levels, whereas for a broader literature analysis the reader is referred to the recent review discussed in Brođanac et al.’s paper [2]. We will then conclude this background section with a couple of notes about the Ministerial guidelines that apply to our school system.

2.1 Parallel and Concurrent Programming at the University Levels

A range of works on the learning of concurrent programming at the undergraduate or graduate levels examine students’ performance, their common difficulties, their understanding of and misconceptions on the subject. For instance, Choi and Lewis [5] analyze and classify the pitfalls in a collection of simple multi-threaded programs written by students in order to improve instruction and develop learning aids. While focusing on thread-safe Java classes, Fekete [7] identifies suitable learning outcomes and discusses related pedagogical difficulties, also proposing examples that could help students avoid common misconceptions. Lönnberg & Berglund [16] investigate the defects of concurrent programs produced by students from a program development perspective.

A recurrent theme at the undergraduate level is whether these topics should be taught in a dedicated course [16, 21], split into multiple units [11, 13], or covered in an introductory programming course [3, 13]. In this respect, Zhu et al. [25] argue that the conceptual shift from sequential programming to concurrent and parallel programming is notoriously difficult to make. The authors present their results of using the educational game Parallel, focusing on the learners’ self-efficacy and how they learn concurrency concepts, and show that undergraduates’ self-efficacy correlates with the time students spend in multi-threaded problem-solving. Formerly, Bruce et al. [3] had suggested making use of graphics and animations in order to facilitate student learning through visual feedback.

No matter how challenging the subject is, Gardner argues that, in light of the current developments of multi-core architectures, refraining “from teaching parallel programming to CS undergraduates is a kind of educational malpractice,” since computer technology cannot be expected “to turn back to the old, comfortable path of ever-increasing uniprocessor clock speeds [...]. To be prepared for careers in this emerging environment, our students need to be furnished with the knowledge and practice of parallel programming” [9, p. 3:6]. And Rivoire [21] reported that upper-level undergraduates were indeed interested in and satisfied with the contents of an introductory course on multi-core programming models. However, according to Ko et al.’s teaching experiences in multiple courses [13], 1st and 2nd year students can recognize parallelism in programming tasks and are generally aware of synchronization issues (although would prefer to approach this subject in later years). In addition, Conte et al. [6] claim that the achievements in parallel programming of novices without previous exposure to computing concepts appear to be comparable to those of more advanced students.

2.2 Parallel and Concurrent Programming in High School

Although concurrent programming has usually been considered exceedingly challenging in a pre-tertiary context, sporadic attempts to introduce this topic in high school date back to the mid ’90s. According to Rifkin, for instance, “it is never too early to teach so-called ‘hard’ concepts” such as basic principles of parallel algorithms and software engineering, providing the ideas are presented “in a manner that is simple, fun and suited to the audience” [20, p. 26].

Much work on the teaching and learning of concurrent programming in the upper secondary school has been done by the Israeli CS Education community. In particular, in the context of a high school unit in concurrent and distributed computing, Ben-Ari & Kolikant [1] explored the evolution of students’ conceptions and attitudes, and found that they were eventually able to develop parallel algorithms and to prove their correctness. Although the involved students initially felt extremely challenged, they then came to appreciate the relevance of the topic and its contribution to improving their cognitive skills. Later, Kolikant observed that, although high school students are able to gain a “rich” understanding of various synchronization tasks, quite often their successful solutions to synchronization problems are achieved by a pattern-based approach “exempting them from dealing with the dynamics of the synchronization mechanisms,” so that the underlying “concepts become inert” [14, p. 243].

Also in Tobert et al.’s view [23] there is ample evidence that parallel algorithmic thinking and multi-threading can be taught—and should be broadly covered in CS education—as early as high school. Moreover, Brođanac et al. [2] have recently conducted an investigation in 3 Croatian high schools where parallel programming was included in the informatics curriculum. They report getting positive feedback from students as to the interest and usefulness of the learnt content, even though it was perceived as more difficult compared to the other topics. The authors conclude that parallel programming, including synchronization issues, can be taught in a high school context at least as an optional subject.

2.3 High School Ministerial Guidelines in Italy

We conclude the background section by briefly summarizing the implications of the Ministerial guidelines framing our Country’s secondary school system. Rather than prescribing a detailed syllabus, such recommendations are meant to be a reference for the teaching of each covered subject. In the case of technical high schools with specialization in Computer Science, the guidelines are articulated in terms of knowledge, skills and competencies to be achieved in the second biennium (grades 11 and 12) and in the last year (grade 13).

Fig. 1.
figure 1

Structure of the survey. More details in Appendix: Survey Questions

Full size image

As to the second biennium, in terms of knowledge students are expected to learn the components of operating systems, including techniques and technologies for concurrent programming and for the synchronized access to shared resources; in terms of skills, they should eventually be able to design and develop applications that interact with the operating system, using whenever appropriate concurrent programming strategies. In their last high school year, students should acquire knowledge on methods and technologies for network programming, as well as on protocols and communication languages of the application layer; in terms of skills, they are trained to develop applications that leverage network communication, such as client-server applications through simple communications protocols.

Within this framework, while teachers still have the freedom to personalize the course organization, concurrent programming is nonetheless considered an essential part of the high school curricula in Computer Science.

3 Instrument

In this section we outline the survey structure and the rationale underlying its design. The general organization, summarized in Fig. 1, is partly drawn from a similar instrument developed and used by the authors to get insight about the learning of other programming concepts [22]. Overall, it includes 24 items, 11 of which are based on 4 small tasks—7 program comprehension questions and 4 evaluations of self-confidence on the provided answers in a 4-grade Likert scale. The full survey is reported in the Appendix: Survey Questions.

The questions addressing the learning of concurrency concepts elaborate on Choi and Lewis’ [5] “catalog” of errors that students typically make when approaching multi-thread programs, particularly in connection with data race conditions, deadlocks and other synchronization issues. To accommodate for the common practice in the involved high schools, the code is Java-like. The first two tasks draw inspiration from programs proposed by Meyer at al. in “Concurrent Programming with Java Threads”,Footnote 2 and are intended to test students’ ability to anticipate the outcomes of concurrent threads. The other two tasks elaborate on Fekete’s work [7]: the third task is meant to see if students are able to identify, among 5 options, both (equivalent) appropriate code fragments to deal with a shared resource; the fourth one requires to recognize deadlock-prone code and figure out suitable corrections.

For the solutions of each of the four tasks, the students were also asked to indicate their perceived level of self-confidence in a Likert scale ranging from 1 (not confident at all) to 4 (fully confident). We included these items because of the potential pedagogical implications pointed out, e.g., in [18, 19], as well as in order to assess the extent to which students’ subjective perception of difficulty correlates with their actual performance on a task. The concluding survey sections concern potential graphical/visual tools that could help understand concurrent programming and possible additional suggestions to improve the instructional practice. A particular interest in graphical/visual tools is motivated by recent research findings suggesting that students of STEM domains are more likely to exhibit a visual-spatial cognitive style [24].

4 Results

4.1 Data Collection

The survey was administered to 68 fifth-year students (grade 13: age range 18–19; 60 boys and 8 girls) attending a CS curriculum in two technical high schools in the North-East of Italy. The students, who were taught concurrent programming in the previous school year, engaged in the task in a controlled situation, under the supervision of their teachers. They were expected to complete the survey within an hour. The answers to the survey were registered only anonymously, and then could not be used for formative or summative assessment.Footnote 3

4.2 General Thread-Related Concepts

Here we summarize the results of survey Sect. 2 (see Fig. 1). To begin with, more than two thirds of the students find thread programming difficult (57%) or very difficult (12%) and report to be unsatisfied (54%) or completely unsatisfied (13%) with their performance in thread-related tasks. Conversely, most of them consider the time spent to deal with the subject (67%) as well as the proposed programming tasks (63%) to be both adequate to the purpose.

At a finer level of granularity, the bar chart in Fig. 2 shows students’ perceived difficulty for diverse thread-related concepts.

Fig. 2.
figure 2

Students’ difficulties with a range of thread-related concepts.

Full size image

As can be seen, synchronization and dealing with thread states are regarded as difficult to learn by 77% and 74% of them, respectively, whereas several aspects in connection with the organization of the classes implementing threads seem less critical. Although to a lesser degree, the answers to the following question, using a similar Likert scale and concerning a range of specific technical program tools, essentially confirm this picture: looking at the hardest side, the Java keyword synchronized turns out to be difficult for about 40% students and the methods wait and notify/notifyAll, governing the thread state, for roughly one third of them. The last question of survey Sect. 2 focuses on managing shared resources. All such related aspects are perceived as difficult by a significant percentage of students, ranging from about 30% (reading/writing operations) to about 60% (synchronization operations).

4.3 Program Comprehension Tasks

In summary, the first task presented a very simple class aimed at synchronizing the access to a shared resource, based on availability of data. Four temporal sequences of methods invocations by two concurrent threads were then presented, with a request to identify the resulting outcomes (questions a–d). The second, more complex task was about an instance of the producer-consumer scheme; again, students were asked to identify the correct output. In the third task, the (two) sound implementations of a straightforward synchronization scheme were to be recognized among five options. Finally, the last problem asked to choose a suitable strategy, informally described in words, to fix a given deadlock-prone code. (The full text of these tasks can be found in the appendix.)

In Fig. 3a are reported the percentages of (fully) correct answers to the seven questions asked for tasks 1–4. As we can see, only the solution of subtasks 1a and 1b are correct for a large majority of students; in all the other cases, less than half of them was successful, with the worst performances taking place for the apparently easy subtasks 1c and 1d. Figure 3b depicts the overall distribution of self-confidence levels between correct and incorrect answers. In this case, since there was one such Likert evaluation for each task, the solution of task 1 is considered correct when all four related answers are correct. Besides evidencing that less than one third of the students are more confident than not about their answers, what once again confirms their difficulties with concurrent programming, the diagram clearly shows that students’ self-confidence in the provided solutions is only weakly connected with their actual achievements.

Fig. 3.
figure 3

Students’ performance in the proposed tasks and perceived self-confidence in connection with their correct and incorrect answers.

Full size image

We also tried to look in more depth at the relationships between quality of students’ answers and perceived levels of self-confidence. To this aim, we scored the performance on task 1 in terms of number of correct solutions to questions a–d, and the performances on the other tasks by distinguishing three quality levels: 1 (= severely incorrect), 2 (= incorrect) and 4 (= correct) for tasks 2 and 4; 1 (= incorrect), 3 (= partly correct) and 4 (= fully correct) for task 3. The correlations and the corresponding statistical significance are summarized in Table 1, which should be self-explanatory.

Table 1. Correlation between students’ performance in the tasks and their perception of self-confidence in the provided answers (in a Likert scale 1–4); the correlation cannot be taken as statistically significant if p-value > 0.05.
Full size table

4.4 Possible Learning Aids and Additional Suggestions

The last section of multiple-choice questions focused on possible graphical/visual learning aids. 59% students reported having thought about using graphical diagrams, and as many as 88% believe that a graphical representation could be effective to improve their understanding of concurrent programming. However, fewer students have a clear idea about which type of tool would be best suited to deal with thread-related concepts. After all, the most effective tools that may perhaps be used are not widely known in school contexts: in particular, several students did not know about Petri nets (74%), Wait-for/Holt graphs (51%), or finite-state automata (50%). Thus, the tools considered most useful for understanding were flow-charts (51% of positive ratings) and block diagrams (43%), even though they are not the best suited to the purpose.

The final open answer was answered by 45 students and 12 of them suggested to introduce examples of increasing difficulty more gradually (e.g. “exercises and examples of more gradual difficulty”). Other recurrent proposals include the use of concrete, real-world examples (6 – e.g. “examples and exercises drawn from the real world [...]”); the use of graphical/animation aids (6 – e.g. “make more use of graphical representations [...]”); a deeper theoretical discussion.

5 Discussion

First of all, we discuss the research questions raised in the introduction.

Q1 – To what extent are students at ease with some basic concepts of concurrent programming? All findings summarized in the previous section—answers to subjective perception questions, actual performance in the proposed tasks and self-confidence in the provided solutions—consistently indicate that concurrent programming is a rather challenging subject for high school students. This is not surprising, in that it corroborates what other educators have observed, by analysing both learners’ performance (more often at the tertiary instruction level, e.g. [5, 23]) as well as their subjective perception. In the latter respect, in particular, Brođanac and colleagues [2] report that concurrent programming is perceived by the high school students involved in their investigation as more difficult than several other programming topics.

Q2 – To what extent does students’ perception of self-confidence correlate with their actual performance in simple concurrent programming tasks? To the best of our knowledge, this kind of analysis does not appear in previous studies specifically addressed to concurrency. The statistics listed in Table 1 indicate that, overall, students’ self-confidence in the provided solutions tends to only roughly correlate to their actual performance in the tasks at hand—and, more in general, they express a low self-confidence level in relation to the considered subject. The discrepancy between self-confidence and performance is especially marked relative to the first task, where higher levels of self-confidence align with wrong answers for subtasks 1c and 1d—so suggesting some lack of awareness about their difficulties, even for a simple problem.

Q3 – What are their major difficulties when learning concurrent programming? As pointed out in Sect. 4, dealing with synchronization and with thread state transitions (via wait/notify operations) represent major challenges. Such difficulties emerge both from students’ perception and from their performance in synchronization tasks. Once again, this confirms previous results that synchronization mechanisms are common sources of students’ mistakes, see e.g. [5, 7]. In connection with synchronization tasks, it may also be worth observing that students’ performance in subtasks 1c and 1d is significantly worse than that in task 2 (see Fig. 3), although the program in the latter case is far more complex. A conceivable explanation of a similar phenomenon is that envisaged by Kolikant [14] and mentioned in Sect. 2: a successful solution for task 2 may be achieved by analogy with a stereotypical producer-consumer pattern, without being concerned with the details of the underlying mechanisms.

Limitations. The present study has been conceived with an exploratory character, in order to gather preliminary insight into a range of aspects in connection with the learning of concurrent programming in the context of our school system. Of course, each such aspect would be worth a specific, more focused investigation, possibly involving larger student samples in a wider geographic area.

Implications for Educators. Mastery of basic concepts of concurrent programming is a cognitively demanding endeavor that, in order to nurture meaningful learning, requires much pedagogical effort and time spent on the subject. As also pointed out by multiple students, teachers should be particularly careful to choose an appropriate set of examples of gradually increasing complexity. An additional issue worth being considered is the use of graphical/visual aids, especially to support the integration of spatial abilities into the learning process [4, 24]. A range of existing tools has been reviewed, e.g., by Libert & Vanhoof [15]. Finally, the low correlation between self-confidence and performance suggests that more attention needs to be paid to students’ metacognitive skills [18], possibly by offering them “opportunities for empirical validation of their knowledge” and explicit instruction in this respect [19, p. 148].

6 Conclusions

In this paper we have presented the results of an exploratory investigation, carried out via a survey, addressing high school students’ perception, proficiency and self-confidence when dealing with concurrent programming tasks. While the main implications of our findings are discussed in the previous section, appropriate decisions about the potential role of this subject in a high school context, and specifically in our school system, are bound to find a reasonable trade-off between two opposite poles: on the one hand, the relevance of the topic from a professional perspectives [9]; on the other, the high cognitive challenge [2] in light of learners’ maturity and teaching time available to develop the subject.

Future Perspectives. Besides designing and planning more focused investigations to overcome the limitations mentioned above, a shorter-term goal could be to administer the current version of the survey in other technical high schools following heterogeneous approaches to the teaching of concurrent programming, with the aim of assessing the extent to which different instructional approaches influence students’ perceptions and/or achievements. Further research could be devised in order to evaluate and compare the effectiveness of different graphical/visual tools to improve the understanding of thread-related concepts.