Louise Giraudet

Marie-Eve St-Louis

Mickaël Causse

Electrophysiological correlates of inattentional deafness: no hearing without listening

The analysis of airplane accidents reveals that pilots sometimes purely fail to notice yet critical auditory alerts. This inability of an auditory stimulus to reach consciousness has been recently coined under the term of inattentional deafness. Recent data from literature tend to show that tasks involving high perceptual load consume most of attentional capacity, leaving little for processing any taskirrelevant information. In addition, there is a growing body of evidence for a shared attentional capacity between vision and hearing. In this context, the numerous displays in cockpits are likely to produce inattentional deafness. A simplified piloting task was conceived, in which participants were required to make decisions based on complex visual indicators while continuous electroencephalographic (EEG) measurements were performed. During the task, a tone was played, either standard, which participants were told to ignore, or deviant ("the alarm", probability = 0.10) which participants were told to report. Preliminary behavioural results showed that up to 30% of deviant sounds were not detected. The analysis of EEG showed that a drastic diminution of the auditory P300 amplitude was concomitant with the occurrence of the inattentional deafness phenomenon. Applications concern integrative online prevention of alarms omission, mental workload measurements and enhanced warning designs.

Introduction

In aeronautics, the use of auditory alarms is widespread. Although one cannot question their efficacy [START_REF] Wheale | The speed of response to synthesized voice messages[END_REF], they seem to come with some limitations [START_REF] Edworthy | Improving auditory warning design: Relationship between warning sound parameters and perceived urgency[END_REF]. Many accidents are indeed due to pilots failing to react to the triggering of an auditory alarm [START_REF] Bliss | Investigation of alarm-related accidents and incidents in aviation[END_REF]). An explanation is to consider the role of the sustained perceptual and attentional processes engaged in the cockpit. There is evidence that tasks involving high perceptual load consume most of attentional capacity, leaving little or none remaining for processing any additional information (see [START_REF] Lavie | Perceptual load as a necessary condition for selective attention[END_REF]. Consequently, high-load contexts tend to prevent the perceptual processing of task-irrelevant information and facilitate various forms of inattentional blindness [START_REF] Mack | Inattentional blindness[END_REF]. This propensity to remain unaware of unexpected though fully perceptible stimuli is not limited to vision, however. Indeed, there is evidence that unexpected salient sounds can remain unnoticed under attention-demanding settings (e.g., [START_REF] Spence | Speech shadowing while driving: on the difficulty of splitting attention between eye and ear[END_REF][START_REF] Fuchs | The Oxford Handbook of Auditory Science: Hearing[END_REF][START_REF] Hughes | Cognitive Control of Auditory Distraction: Impact of Task Difficulty, Foreknowledge, and Working Memory Capacity Supports Duplex-Mechanism Account[END_REF][START_REF] Wood | The cocktail party phenomenon revisited: Attention and memory in the classic selective listening procedure of Cherry (1953)[END_REF]. Although less well-known than its visual counterpart, this inattentional deafness phenomenon (Koreimann et al., 2009) is likely to have important consequences for safety-critical situations such as military or commercial flights as pilots are often overloaded with visual information. Yet the classical view of shared attention hypothesizes is that each sensorial modality owns a separate pools of resources. Hence, two tasks from different modalities (e.g. auditory and visual) should not interfere with each other [START_REF] Wickens | Multiple resources and performance prediction[END_REF]. However, this view could be partially unfounded as a growing body of literature provides evidence of attentional abilities shared between visual and auditory modalities [START_REF] Brand-D'abrescia | Task Coordination between and within sensory modalities: Effects on distraction[END_REF][START_REF] Santangelo | The suppression reflexive visual and auditory orienting when attention is otherwise engaged[END_REF][START_REF] Sinnett | Manipulating inattentional blindness within and across sensory modalities[END_REF].

Interestingly, [START_REF] Macdonald | Visual perceptual load induces inattentional deafness[END_REF] demonstrated that participants involved in a visual discrimination task were subject to inattentional deafness. Occurrences of inattentional deafness were even greater when the visual task involved a high level of perceptual load compared to low perceptual load. Under the assumption that attentional resources are shared between vision and hearing, it appeared that engaging in a task under high visual load may lead to a decline in the probability of processing an auditory stimulus. Therefore, a parallel can be drawn with aeronautics, where cockpit displays obviously generate a high perceptual and mental load. Lavie's load theory (1995) would henceforth predict that the primary task, i.e. piloting, would engage most of attentional resources. Few resources would consequently be available for processing additional information such as an unexpected auditory alarm, facilitating the inattentional deafness phenomenon.

Uncovering the neural correlates of inattentional deafness

The brain activity involved in processing auditory information has been particularly studied using Electroencephalography (EEG) techniques to measure Event-Related Potentials (ERPs). P300, one of the most commonly studied ERPs, is known to be induced by oddball paradigms that consists in the detection of an attended and unpredictable target stimulus [START_REF] Polich | Updating P300: An integrative theory of P3a and P3b[END_REF]. It reflects cognitive and attentional processes between 300 and 500 ms post-stimulus (see [START_REF] Hansenne | Le potentiel évoqué cognitif P300 (I): aspects théorique et psychobiologique -The P300 event-related potential (I) : Theoretical and psychobiological perspectives[END_REF], for a detailed review). When attentional focus deviates from the target, the P300 amplitude significantly decreases [START_REF] Singhal | Effects of a dual task on the N100-P200 complex and the early and late Nd attention waveforms[END_REF]. Therefore, P300 seems an excellent candidate to determine whether an auditory stimulus has broken through the attentional barrier. While several studies have revealed that auditory P300 amplitude may be lowered in audio-visual dual-tasks compared to auditory task alone [START_REF] Armstrong | Neural markers of automatic and controlled attention during immediate and delayed action[END_REF][START_REF] Ramirez | Influence of a visual spatial attention task on auditory early and late Nd and P300[END_REF][START_REF] Singhal | The differential effects of Sternberg short-and long-term memory scanning on the late Nd and P300 in a dual-task paradigm[END_REF][START_REF] Wester | Event-related potentials and secondary task performance during simulated driving[END_REF], the association between the inattentional deafness phenomenon and P300 has never been investigated.

Objective and hypotheses

Two main objectives were set during this work. Firstly, contrary to Macdonald and Lavie study (2011) in which only one occurrence of the inattentional deafness phenomenon was successfully reproduced (in their experiment, further attempt failed due to the impact of the pre-exposure to the sound), we aimed at designing an experimental paradigm allowing a sufficient number of occurrences of the inattentional deafness phenomenon within each participant to perform ERPs. Secondly, we intended to measure the inattentional deafness rate considering several visual/mental load conditions and to examine the possible concomitance between inattentional deafness and P300 modulations. For this purpose, we performed EEG measurements during a simplified but plausible aviation decision-making task in which participants were asked to take into account both visual and auditory signals. Auditory signals were based on the oddball paradigm to enhance the P300.

Our hypothesis was that an increase in visual/mental load should provoke a decrease in the alarm detection rate (deviant sounds) and a concomitant reduction of the P300 amplitude, suggesting that increased visual/mental load directly affects the cerebral response to an auditory stimulus, providing physiological explanation regarding the inability of pilots to perceive auditory warnings in the cockpit during critical flight phases.

Method

Participants

Sixteen male right handed healthy volunteers (mean age = 20.9 years, SD = 1.22) were recruited at ISAE Supaéro for this study. All participants were French undergraduate students, none of them had a history of neurological disease, psychiatric disturbance or substance abuse, or was under psychoactive medications. They were given full information about the experiment protocol and all gave their informed consent. Of these, one was excluded because his error rate in the control trials was above 15%. The 16 participants went through the same procedure, which began with a fatigue assessment using Pichot's fatigue scale. Participants having a score over 22 would have been excluded, considered excessively tired. Then they performed the Paced Auditory Serial Addition Test (PASAT) to assess their working memory. No participant obtained a prohibitive score during this test (below 35% for the PASAT 3'' or below 23 for the PASAT 2''). Finally they completed a laterality test to confirm they were right handed.

EEG recordings and pre-processing

EEG data were recorded continuously with a Biopac EEG system. Before the experiment, a 19-electrodes cap (CAP100C) was placed on the participants' head. 7 electrodes were analysed, distributed throughout the brain volume: Fz (frontal), Cz (central), Pz (parietal), T4 and T7 (temporal), O5 and O18 (occipital). The Biopac was connected by parallel cable to the experimental computer in order to mark trial onsets on EEG data. Three electro-oculographic electrodes (EOG) were placed on the left, on the right and above the eyes to record the muscular eyes activity. Artefacts created by eyes movements were removed online from the cerebral signal with Acqknowledge 4.0 EOG artefacts removal function.

Tasks

Two different tasks were presented: a decision-making task, called the landing task, and a classical oddball task. The oddball task was performed according to three experimental conditions: 1) during a low-load landing task (visual load = 1), participants simultaneously performed the oddball task and the landing task at a low load level; 2) during a high-load landing task (visual load = 2); 3) in the baseline oddball session were no parallel task was performed (load = 0), as in the classical oddball paradigm. Differently from Macdonald's design, participants were asked to report it each time they heared the tone was a alarm. This way, the phenomenon of inattentional deafness could occur more than once on the same participant. First, participants went through the dual task session, performing both the landing task and the oddball task at the same time. Low and high load trials of the landing task were interspersed throughout the session. Then they completed the baseline oddball session, performing only the oddball task to give us their nominal response to the auditory stimuli.

The baseline oddball session. Participants performed the oddball task, consisting in a set of 200 trials in which 200 tones were played. Each trial presented a first time window lasting 2 to 4.5 second during which the tone was played, followed by a 2 seconds response time window, during which participants had to make their response if they noticed a deviant tone. Continuously during the session, a white noise at 50dB was played. During each trial, a 30dB tone was randomly played (between 500 milliseconds after the beginning and 500 milliseconds before the end of the first time window) during 150 milliseconds. This tone was either standard (frequency = 1900Hz, p = 0.8) or deviant (frequency = 1950Hz, p = 0.2), according to the oddball paradigm. To report their awareness of a deviant tone, participants pressed the central button of a three buttons response box. No response was to be given when the standard tone was played. The 2 seconds response window elapsed regardless of whether a response was made. Percentage of reported deviant tones was the dependant variable.

The dual task session. Participants were submitted to a set of 400 trials, during which they simultaneously performed both the oddball task and the landing task. In each trial, a 2 to 4.5 seconds video was displayed, followed by a 2 seconds response time window, during which participants had to make their response. During the videos (see figure 1), various indicators appeared on a screen: heading, magnetic declination, wind and score, which were fixed during the video, and the two ILS (Instrument Landing System) moving cursors, one vertical and the other horizontal. This video was followed by a 2 seconds response window, as during the baseline oddball session. During this response window, all indicators were frozen and still displayed on the screen. To answer correctly to the landing task, participants had to decide whether the landing was possible or not, according to rules shown in figure 2, based on the final values of the indicators at the end of the video, by pressing a button on a response box. Two buttons on the response box were dedicated to the response to the landing task: the right one to authorize landing, the left one to abort it. For each correct response, the score increased of 1 point. When participant missed a response, or made an incorrect response, this score did not increase. The score system was introduced to motivate the participants to perform the landing task. Two levels of visual/mental load were manipulated and equally likely to occur (see figure 1). For the low load condition, indicators appeared in green and no mental arithmetic had to be performed to deduce the rule to apply to the cursors positions. In high load conditions, the indicators appeared in red, the cursors were moving faster and mental arithmetic had to be performed to deduce the rule to apply to the cursors positions. To further increase the visual load involved by this task, a coloured circle was displayed during 150 milliseconds during each video, at a random time. This circled was either red (probability = 0.9) or green (probability = 0.1) and equally likely to be displayed on the right or on the left of the screen. A red circle was considered to be a visual alarm and had to be reported during the response window by pressing the central button on the response box. The circle was at least 500ms apart from the time the tone was played. The red circle could not be displayed when a deviant tone was played in the same trial, so that only one alarm top had to be reported per trial. For the oddball task they had to perform in addition to the landing task, during the 2 seconds response window, participants had also to press the central button of the response box if they heard a deviant tone. It reflected their ability to detect the auditory alarms (deviant tones) while performing a primary task. Percentage of correct response to the landing task and percentage of reported deviant tones were the dependant variables. The landing task was also displayed during the baseline oddball session, but participants only had to perform the oddball task. Participants were instructed that they should not pay attention to the landing task, reporting only the deviant tones.

Procedure

The whole procedure lasted 150 minutes, including 30 minutes to install and test the equipment and 60 minutes of EEG recording. After the behavioural tests, participants were all trained for the three experimental conditions during two sets of 20 trials for each, which contained all the possible situations they would encounter in the real experimentation. During this training, participants had to attest to the notification of both visual and auditory alarms, responding correctly to the alarm detection task at least once for each type of alarm. Then the EEG electrode cap, EOG and GSR electrodes were placed, prepared and tested. Participants seated then in a comfortable reclining armchair, placed in a dimly lit, sound-damped room. They were instructed to keep their forearms lying on the chair's arms, with their two hands resting on the response pad. The 400 experimental trials lasted 40 minutes.

Participants then answered the NASA Task Load Index (NASA TLX) to give a detailed evaluation of their performance to the landing task and to the alarm detection task. Finally, participants had to go through the 200 baseline oddball trials (20 minutes).

Results

All statistical analyses were performed using IBM SPSS 20. Results were considered statistically significant when p < .05.

Performance measures

A t-test for paired samples indicated that the detection rate in the baseline oddball session did not differ in the low load condition (M = 96.67%, SD = 5.88%) and in the high load condition (M = 97.33, SD = 4.17%), t(14) = .619, p = .546. Therefore, both conditions were merged into one "control condition" for subsequent analyses.

Correct response rate to the landing task was assessed by a 2 x 2 ANOVA with within-subjects factors "load" (low or high) and "type of tone" (standard or deviant) in order to investigate the differences between conditions. The main goal of this analysis was to make sure there was truly a difference between the low load and the high load conditions and that participants followed instructions and accomplished the landing task as the primary task. If those assumptions were met, the performance would be higher in the low load condition than in the high load condition, and the type of tone would not affect performance. Results corroborated those two hypotheses. Correct response rate to the landing task in the low load condition (M = 96.7%, SE = 0.6%) was superior to the correct response rate in the high load condition (M = 90.2%, SE = 0.7%), F(1, 14) = 91.596, p < .001. There was no difference between trials with the standard tone (M = 93.2%, SD = 0.9%) and trials with the deviant tone (M = 93.8%, SD = 0.5%), F(1, 14) = .385, p = .545, and no interaction, F(1,14) = .002, p = .968.

Detection rate for the oddball task was examined. A t-test for paired samples showed that deviant tones were more detected in the low load condition (M = 80.17%, SD = 21.54%) than in the high load condition (M = 71.52%, SD = 26.67%), t(14) = 2.385, p = .032, as shown in figure 3.

ERPs measures

The P300 component was examined through a 3 x 3 x 2 ANOVA with withinsubjects factors "electrode" (Fz, Cz or Pz), "load" (control, low or high), and "type of tone" (standard or deviant). Significant main effects were found for the electrode, F(2, 28) = 17.068, p < .001, the load F(2, 28) = 17.810, p < .001, and the type of tone, F(1, 14) = 8.948, p = .01. There were significant interactions between electrode and load, F(4, 56) = 3.525, p = .012, and between electrode and type of tone, F(2, 28) = 16.261, p < .001, but no other interaction was observed.

Simple main effects and multiple comparisons were further analysed using the LSD test. P300 were larger at the Pz (M = 5 μV, SE = .25 μV) than at the Fz (M = -1.1 μV, SE = .35 μV), p < .001, and the Cz (M = -.8 μV, SE = .35 μV), p < .001, recording sites, whilst Fz and Cz showed no difference, p = .276. The largest ERP was observed with the control condition (M = 1.55 μV, SE = .5 μV), followed by the low load condition (M = -.25 μV, SE = .55 μV), p = .027, and the high load condition (M = -2.7 μV, SE = .45 μV), p < .001, which also differed significantly, p = .001 (see figure 4). Finally, the deviant tone (M = .1 μV, SE = .4 μV) showed a higher P300 than the standard tone (M = -1.05 μV, SE = .25 μV), p = .01.

More specifically, for the three electrodes, the high load condition generated a lower P300 than the low load and the control conditions when the tone was standard, all p < .01, but there was no significant difference between the control condition and the low load condition on any of the recording sites. For the trials featuring a deviant tone, the pattern of results was the same, with the smallest P300 in the high load condition compared to both the low load and the control conditions, all p < .01. The Fz and Cz electrodes also showed no difference between the control and the low load conditions, but this difference appeared to be significant for the Pz electrode, the baseline oddball condition producing the highest P300, p = .038.

Again for the three recording sites, the difference between the standard and the deviant tones did not prove significant in both the low load and the high load conditions. In contrast, in the baseline oddball condition, the deviant tone generated a stronger P300 than the standard tone for the Cz and the Pz electrodes, respectively p < .05 and p < .001, whilst this difference did not appeared with the Fz electrode, p = .122.

Discussion

Our study aimed at creating an experimental paradigm in which the inattentional deafness phenomenon could occur numerous times with each participant. We designed a simplified landing task with two levels of visual/mental load. While participants were subject to this task, an oddball paradigm was administered simultaneously to assess their ability to detect an alarm (i.e. the deviant sound in the oddball paradigm). We hypothesized that variations in visual/mental load will modify the ability of our participants to detect the alarm, generating inattentional deafness. In addition, we assumed that the diminution of the auditory P300 amplitude should be concomitant with the occurrence of inattentional deafness, and that this diminution of amplitude should be related to the visual/mental load level.

The behavioural results showed that our task was successful in reproducing inattentional deafness. Whereas only 5% of alarms were missed during the baseline oddball session (oddball task only), 20% of alarms were missed when the oddball task was processed simultaneously with the landing task under low load condition, and this number increased to 30% under the high load condition. This is consistent with the results obtained by [START_REF] Macdonald | Visual perceptual load induces inattentional deafness[END_REF] in which increased visual load was more likely to provoke inattentional deafness.

The effect of the introduction of visual/mental load on the ability to detect an alarm was significant in both behavioural results (number of sounds omitted) and electrophysiological measures, as showed by the variation in amplitude of the P300 component. Auditory P300 diminished in the landing task with low-load condition in comparison to the oddball baseline and further diminished with an increase of the load (high load vs. low load). These results confirmed that the primary task left few resources to treat auditory alarm in the low-load condition and even fewer in the high-load condition. It supports the hypothesis of a common pool of resources shared between visual and auditory modalities [START_REF] Macdonald | Visual perceptual load induces inattentional deafness[END_REF].

Variations in P300 amplitude also raise the question of short term memory effects on inattentional deafness occurrences and ERPS measurements. A difference due to memory (Dm) has been observed in ERPs measurements with memory paradigms [START_REF] Friedman | An event-related potential study of encoding in young and older adults[END_REF], in which participants study a list of materials and trials are sorted as a function of whether they go on to remembered or not in a subsequent test phase. Such paradigms being very demanding on the short term memory, involving lists of several items to be remembered, and the test phase taking place separately and significantly after the study phase (several seconds to several minutes), we tried to avoid Dm effects by minimizing the amount of information to keep in mind in each trial and by reducing the duration during which information had to be remembered: no information had to be remembered for more than 4 seconds. Furthermore, the amount of information to manage was the same in each trial. Under such conditions, we prevented the most participants from simply forgetting they heard the alarm before having to report it, and short term memory was equally solicited in every trial so that no defference due to memory could affect participant's performance or measurements. We then assumed Dm was not significant in this experiment.

The major contribution of this study lies in the co-occurrence of inattentional deafness and ERP measurements. While inattentional deafness was studied through behavioural questionnaires following a single trial (Koreimann et al., 2009[START_REF] Macdonald | Visual perceptual load induces inattentional deafness[END_REF], we developed a paradigm inducing multiple occurrences of inattentional deafness in a participant, rather than a single irreproducible occurrence in behavioural studies conducted so far [START_REF] Macdonald | Visual perceptual load induces inattentional deafness[END_REF]. Another specific contribution of this work is the development of measurements of brain activity to electro-physiologically characterize the state of an operator suffering from inattentional deafness. EEG analysis showed that a drastic diminution of the auditory P300 amplitude was concomitant with the increased occurrence of inattentional deafness.

Conclusion

This study provides new behavioural and electrophysiological insights to explain the trend of pilots to ignore critical auditory information. We notably demonstrated that mental and perceptual workload interferes with concurrent appraisal of rare and unpredictable auditory alarms. P300 modulations supported this result and provide a more complete characterisation of the internal attentional mechanism responsible for observable behaviour. These results encourage the use of a neuroergonomic approach to study pilots' performance. This multidisciplinary approach, combining methods from neurosciences and human factors, is part of a commitment to improve aviation safety. Additional experiments with more participants and an EEG cap with 128 electrodes will be conducted to enable ERPs source localization and clarify the correlation between ERPs characteristics and the attentional state of a pilot in situations likely to provoke inattentional deafness. Further studies are also scheduled to establish the relevance of this approach to study new auditory alarm designs preventing inattentional deafness and to detect and predict in real time the deficiencies of pilots' attention. This study also opens the way to new paradigms using electrophysiological measurements on real pilots and co-pilots in a motion flight simulator.

Figure 1 .Figure 2 .

 12 Figure1. screenshots of a low load landing task video (on the left) and a high load landing task video (one the right). On the upper left corner is the heading to be added to the magnetic declination below. On the right is the wind. On the upper right corner is the current score to the landing task.

Figure 3 :

 3 Figure 3: Detection rate of deviant tones depending on the perceptual and cognitive load of the primary task. "Control"represents the baseline oddball session.

Figure 4 :

 4 Figure 4: P300 mean amplitude and standard deviation in µVolts depending on the perceptual and cognitive load of the primary task, for target tones on Pz electrode. "Control"represents the baseline oddball session.


Henri Delebecque
email: henri.delebecque@supelec.fr

LEARNING PROCESS SYNCHRONIZATION INTERACTIVELY

Keywords: Pedagogical simulator, computer science, process synchronization. 2

Teaching Computer Systems Architecture at Supélec involves both lectures and projects. We have defined and implemented a pedagogical simulator intented to teach different synchronization problems. Its main aim is to help students better understand the problems involved in variable sharing between two processes, and allow them to solve the problems, using semaphores. The simulator offers an instruction library based on a pedagogical processor used in the Computer Systems Architecture course. Students will drag-and-drop the instructions into the two instruction lists used for the processes. The overall program should fulfil the global requirements, and produce the right value for the shared variable, regardless of the execution order of the instructions. Students use our code analysis software to check the correctness of their design. If the algorithm detects a failure in the shared variable use, it builds an execution flow that exemplifies the failure. The students can follow the flow, step-by-step, by browsing through a series of on-the-fly computed panels, each one displaying the critical values of the processor registers as well as process description record fields and the current instruction field or a shared variable. The explanation panel includes arrows that point to every information transfer and a short text that describes the current overall status. The analysis and explanation builder software has been designed according to a very simple instruction set of our pedagogical computer. Its principal feature is to reduce the complexity of the student code diagnosis algorithm. The simulator is currently accessible online to our 400 students who have given us a very positive feedback on it. We have now been asked to extend its application to other problems. The possibility of such an extension has been included in the simulator pre-requirements, first by offering an open instruction library, second by designing an analysis tool able to work either with various sets of instruction sequences, or with more than two processes, multiple semaphores and/or shared variables. The most innovative aspect of our pedagogical experience is the ability to explain very precisely the faulty behavior of the code to our students while allowing them to build any sequence of instructions without the burden of conforming to a strict programming language syntax. This allows them to focus on the problem they have to solve, and probably explains why they like it so much. Furthermore, our simulator is expandable to other typical synchronization problems or, potentially, to other instruction sets.

INTRODUCTION

Concurrent programming is difficult both to teach and to learn. Even in simple cases, it involves understanding many concepts, such as the semantics of a processor instruction, the various states of a process, the way in which an operating system describes a process, etc. Moreover, practical experimentation is difficult, due to the non determinism induced by the scheduler.

We will start by describing how Computer Science is taught at Supélec, then we will define the pedagogical aims of our project. This will later on allow us to describe the models and concepts involved. The next paragraph deals with the simulator design, and the last one with related work. We will end with the future developments.

engineering and the programming models. Students become familiar with the usual topics of software development and learn Java as a high level programming language.

One of the two second year courses enables students to master both the fundamental blocks of hardware computer architecture, namely busses, memory chips and modules, interruptions as well as the operating system concepts, such as a process, a thread, a scheduler, memory and input/output management. All students finishing their second year at Supélec have to pass an exhaustive examination in the hardware and operating system domains, during two lab sessions. During the first session they are asked to build a simple computer using a pedagogical hardware simulator we have designed [START_REF] Delebecque | Hands-on Experience for Teaching Computer Architecture using a hardware Toolkit[END_REF]. In the second one they have to design a multi-threaded simulation in Java in which they have to carefully synchronize the threads in order to correctly manage the shared global variables.

The concepts involved in this latter session are multiple, complex, and completely new to our students. Moreover, the global behavior of a set of threads is obviously non-deterministic, since it depends on their scheduling which can change from one execution to another.

The debugging of a set of concurrent threads is considered as a tricky task, since inserting textual outputs (the means often used by students to pinpoint the successive values of a variable) leads to unreliable results in a multi-thread context. Moreover, using breakpoints included in the current IDE (Integrated Development Environment) debugging tools can change the faulty behavior or completely remove errors.

For all these reasons, we have decided to help our students in two ways. First, a specific tutorial proposes a design of a consumer-producer pair of processes, with requirements of an increasing difficulty. Next, we have designed an interactive pedagogical simulator that allows them to solve a rather trivial problem of sharing a variable between two processes, one raises the initial variable value by a constant, while the other, concurrently, decreases the same variable from which is subtracted another constant This article will describe the simulator, both from the pedagogical, ergonomic and technical point of view.

During their third and last year, all students have to specialize in one of fourteen majors, each in a particular field (e. g. communications systems, power electronics, or computer science). Students who choose to major in computer science will have to master the main fields of modern computer systems, attending further theoretical lectures and doing lab work.

PEDAGOGICAL AIMS

We have designed the pedagogical material for the Computer Science courses with the five following pedagogical goals in mind. The first three of them represent general pedagogical principles in our school of engineering, while the last two are specific to the Computer Architecture domain.

Students should focus on the concepts

One of the main purposes of the simulator is to make students able to design and rectify the instruction sequences of the two processes by themselves, since they have to use it outside the mandatory sessions. The Human-Machine interface should be intuitive, and the simulator has to give visual feedback of the students actions, while allowing them to focus on the concepts they should learn. This option obliges the designers to avoid tools that ask students to give instructions textually, as the editing task requires too much time and effort if the students follow strictly a programming language syntax.

We have to keep students in a stable pedagogical background

To help students in their design, we have chosen to keep for the simulator the same instruction set computer they have seen in the computer architecture lectures that start the Computer System Architecture course. Obviously, we have added WAIT and SIGNAL, i.e. the instructions required for manipulating semaphores. The synchronization tool which executes such instructions has been described by DJIKSTRA [START_REF] Edsger | Solution of a problem in concurrent programming control[END_REF].

The semaphore is the main synchronization mechanism described in lectures, practically used during a tutorial devoted to process synchronization problems as well as during the hands-on session described in paragraph two and detailed later. The lecturer presents other techniques, but focuses on semaphores in order to shorten the time spent on this subject.

The simulator should be accessible online

Since specifying and developing such a simulator following the pedagogical and technical requirements described here is time-consuming, we have decided to use it for all second-year students, regardless of the campus they belong to (Gif-sur-Yvette, near Paris, Rennes in Brittany, or Metz in the east of France). This option has obliged the designers to define an online tool hosted by "Moodle", the pedagogical platform chosen by the school. To implement the tool, the development team has chosen Java, since it is the language widely mastered in the school. The simulator is an applet, as this option requires only a lightweight client and allows trivial updates. The disadvantage of using a Java applet, in terms of security constraints and limited processing resources are of less weight in our case since the simulator neither needs to access to the computer's client resources, nor implies heavy computing.

The simulator should be able to manage a large panel of problems

To achieve the same aim of economy, we specify a very open and expandable simulator. Instead of limiting its diagnosis capabilities to the initial exercise, for which crude methods are sufficient, we have chosen to design an analysis algorithm, reusable for forthcoming complex problems. Conversely, after studying many open source tools that can help us in diagnosing the student proposal, we have chosen to design a custom analysis tool. We justify this option by analyzing the available tools.

First, three kinds of tools exist: the static ones that work before (and without) code execution ([3], [START_REF] Boyapati | A parameterized type system for race-free java programs[END_REF]), tools that detect the race conditions during execution ( [START_REF] Savage | Eraser: A Dynamic Data Race Detector for Multi-Threaded Programs[END_REF], [START_REF] Praun | Object-Race Detection[END_REF]), and the post-mortem ones that analyze the log trace of execution to diagnose problems ( [START_REF] Ronse | RecPlay: A Fully Integrated Practical Record/replay System[END_REF], [START_REF] Choi | Deterministic Replay of Java Multithreaded Applications[END_REF]). The last two techniques must either exhaustively investigate all the execution paths, or accept that some errors remain undetected. The first option will lead to heavy computing, even in the case of simple programs (two 10 lines long programs may generate about 1 million different execution paths). It is irrelevant if the process codes contain infinite loops, a very common case in synchronization problems. The second option is forbidden in a pedagogical context, where students need a perfect diagnosis of their solutions.

What remains is the static analysis option. One kind of static diagnosis tool uses high level languages, such as C or Java, extending their type system ( [START_REF] Boyapati | A parameterized type system for race-free java programs[END_REF], [START_REF] Boyapati | Ownership types for safe programming: preventing data races and deadlocks[END_REF], to prevent data races. They are of less interest in our case, since the very simple programming model our students use in Computer Systems Architecture, based on processor instructions, differs considerably from the semantics of these languages, and does not allow for a typing system. Moreover, these tools try to prevent problems by adding locks. The objective is for the simulator to detect rather than remove errors contained in the students's work. Other kinds of tools performing effective detection ( [START_REF] Kahlon | Fast and Accurate Static Data-Race Detection for Concurrent Programs[END_REF], [START_REF] Dabrowski | A Certified Data Race Analysis for a Java-like Language[END_REF]) cannot be used for our simulator, since they only supply a diagnosis, but do not give a typical sequence of an instruction execution that leads to the failure. Moreover some of them tend to report "false warnings", probably due to the fact that they tend to analyze high-level languages which manipulate pointers. Manageable in the industrial systems domain where engineers can deal with it, a wrong detection is not acceptable in a pedagogical context.

The simulator has to explain pedagogically the faulty behavior of the code

As mentioned before, the most crucial goal of our simulator is to carefully explain to our students the mistakes they have made, especially since they work alone. The simulator builds this explanation using the terms and concepts used during lectures and tutorials, and displays all the information required for understanding the faulty behavior of the code.

Moreover, the students are able to browse through the sequence of slides displaying the following states of the system while the processor executes their specific code, either forward or backward, at their own rate. Each slide shows the processor register values (its state), the processor state stored by blocked or waiting processes, the value of any shared variable and the state of each process. A process can be "running" (if the processor is executing its code), "waiting" (it is waiting to run), "blocked" (if it waits is waiting for a SIGNAL to be executed by another process) or "terminated", as shown in Fig. 1.

THE CONCEPTS AND MODELS INVOLVED

The Computer System Architecture course takes only twelve lectures, four tutorials of 1.5 hour each, and two 8-hour practical sessions to teach all the building blocks of a modern computer system. It uses a custom pedagogical processor, built step-by-step in the lectures devoted to computer architecture. More than 20 years ago, Supélec professor decided to define their custom processor rather than to use the well-known Tanenbaum architecture [START_REF] Tanenbaum | Structured Computer Organization[END_REF] since the Supélec processor allows the lecturer to reduce the time spent on explaining both the external and internal processor architectures.

Another advantage of this simple processor is that our students can design, built and test it in the first practical session mentioned earlier. In line with the pedagogical principles explained above, we use the same processor for all the tutorials, the lectures devoted to the acceleration mechanisms (cache memory and pipeline) and the presentation of the process synchronization fundamentals. These fundamentals start from the very simple case of a variable shared between two processes, and describes how the lack of synchronization can lead to a data race giving a wrong final value of the shared variable. The lecturer then presents classic patterns, such as rendezvous, both incomplete or complete, between processes. Finally the lecturer describes the problems that occur when synchronization tools are misused, and the techniques and principles that allow students to avoid committing errors.

The processor

Our processor is equipped with an accumulator, eight instructions (LDA for loading the accumulator, STA for storing it into a variable, ADD and SUB for adding a value to it, or subtracting a value from it, and branching instructions, that allow the processor to jump to another part of the code). It defines only two addressing modes (direct for variables and immediate for constants). It is built using very simple building blocks, presented in the Logic System lectures, such as 16 bits wide registers, a simple arithmetic and logic unit and a 64K 16 bits wide memory, connected together using tri-state buses. A 3 hour lecture starts by describing these blocks and specifying the processor requirements. The lecturer then builds step-by-step the internal data path, and ends by defining the sequencer operations flowchart. An additional tutorial asks students to apply this theoretical knowledge while building another kind of processor, to allow them to separate the general concepts found in any processor from the specific characteristics of a particular one.

DJIKSTRA's Semaphores

The semaphore is the main locking mechanism described in lectures, used intensively during the tutorial devoted to synchronization problems, and the practical 8-hour session that asks student to design, build and test a barbershop simulation in Java.

The tutorial focuses on the analysis and design of two processes, one producing messages it puts into a mailing box, while the second extracts and processes them. The first process should block itself as soon as the mailbox is full, while the other is not allowed to extract a message from an empty box. These requirements describe a classic case of process cooperation, called the producer-consumer problem. We then enlarge the initial specification first by allowing multiple producers and consumers, then by asking an idle consumer process to process an alternative task instead of leaving the process blocked.

THE SIMULATOR DESIGN

To fulfil the requirements described in the paragraph 2, we have specified the simulator in terms of three dimensions: the pedagogical, the ergonomic, and the technical one.

Pedagogical aspects

During the Computer Systems Architecture our students have to assimilate a lot of new concepts in a rather short time. We present these concepts by increasing complexity, the understanding of the last one implying that the earlier ones have been well assimilated. Students who use the simulator work on a voluntary basis without coaching. The simulator should help them as much as possible, either during the process code building, or the diagnosis explanation.

Contextual and immediate help

The simulator offers ready-to-use instructions, stored in an easy to browse panel, instead of asking the student to enter them manually, as shown in Fig. 2.

Figure 2. The processes code input panel

The panel guides students in their design, even if they do not remember the computer instruction set. Practically, the simulator displays the semantics of any instruction, if the student leaves the mouse motionless on a library instruction. During the explanation phase, the simulator exemplifies the impact of an instruction execution by displaying the instruction just executed and the values it has modified in red, and by drawing arrows from the origin of the value to the object that received it, as shown in Fig. 3.

Figure 3. Clear explanation of an instruction execution

The students do not have the burden of looking for the semantics of an instruction, and can focus on the task they should perform: correctly synchronizing the two processes, by understanding where and why their proposal has failed.

Explanation of the scheduling consequences

We also need to prove to our students why a specific arbitrary process scheduling can lead to a faulty behavior by giving a global state description, as shown in Fig. 4. This description clearly explains the cause of any process state change. For example, the simulator tells the students if the process is "blocked" by performing a wait on a semaphore having a counter valued less or equal to zero, if it "terminates", or if it turns "waiting" due to the scheduling policy.

In the Fig. 4 example, the explanation panel both mentions an arbitrary suspension (decided by the diagnosis algorithm to show a faulty code behavior) and stresses the transfer of values this process state change implies. Displaying this information is a crucial point for the good understanding of the race condition. More precisely, the faulty behavior of the code is due to the fact that two different accumulator values exist: on the one hand the real one and on the other the value stored in the context record, restored into the accumulator as soon as the process resumes. This is the reason why the explanation computing phase should carefully chose which process should start first and when to suspend it. We found here a clear justification for avoiding tools that give only a global diagnosis, without an execution path leading to the race condition .

Ergonomic aspects

Since our students may have to change the code they proposed after having understood their mistake, and in order to offer the quickest way to build the first version, we have decided to allow them to dragand-drop the instruction from the library into one of three instruction lists. The first one (in the right bottom corner of Fig. 2) contains the initialization code of the root process. The other two receive the instructions that have to add $200 to (and withdraw $100 from) the shared variable that implements the bank account. For the same reason, students can move an instruction in any instruction lists, either by drag-and-dropping it, or by combining keyboard keys. They can also remove an instruction by selecting it and pressing the delete key.

The applet avoids modal dialogs that tend to keep the user captive, and allows students to navigate freely between the input and explanation panels. This gives them the ability to look at information not displayed on the explanation panel (such as the root process code, or instructions they have not yet used), while keeping the computed explanation slides sequence available for further study. To avoid mistakes, a short user's manual fills in the explanation panel as soon as the students change anything in their code.

Technical aspects

The specification and design of either the user interface, or the two algorithms required by the simulator took about 4 months of full-time work in order to build a version that meets only partially our requirements, but still can be put on-line.

The user interface specification of the input panel has been the first and easier step, while the explanation slides sequence design had to wait until the complete definition of the race-condition detection algorithm principles. As mentioned before, we first looked for existent tools and algorithms, before deciding to write our own. Once we chose this option, we gained more knowledge about the available information necessary to explain the student mistake. Consequently we are now able to specify how to compute the explanation slides sequence, and decide what information each slide will display.

The code analysis begins by looking for not initialized variables and semaphores. Any error of this kind shortens the diagnosis by explaining the problem. The race condition algorithm starts by detecting any code section that begins with a transfer from a variable value into the accumulator, modifies the accumulator, and then stores it in the same variable. We call these zones varZones. The algorithm then checks if such sections are included in zones beginning with a WAIT, and ending with a SIGNAL working on a same semaphore, we called semZones. The algorithm marks varZones outside any semZone as prone to race conditions. During this analysis, the algorithm manages semZones included in another semZone by storing them in its list, and by assigning them an incremented level.

All the zones detected during the first phase are used both to detect race conditions and to produce the sequence of explanation slides. The race condition detection algorithm begins by checking conflicts between the root semZone of the two processes. It checks the kind of semZone (either one starting with a WAIT or a SIGNAL), and also checks whether the first semZone excludes executing the other one until its own end or not. In the latter case, it first asks the other semZone to check for conflicts with its included semZones (in a recursive way), then with its included varZones. Checking varZone conflicts works by comparing the variable affected by both zones. Identical variables lead to race condition which inputs for the building phase of the explanation slides .

RELATED WORK

The earlier 3.4 paragraph mentions many tools devoted to the detection and/or correction of race conditions in concurrent programs. The aim of the current paragraph is to investigate pedagogical tools dedicated to the teaching of concurrent programming. The first one, Visual OS, is an interactive, exploratory environment for learning process synchronization. It allows for visualizing classic synchronization cases (the critical section problem, a Consumer/Producer pair, a Reader/Writer pair, and the well-known dining philosophers problem). Unfortunately, this tool is described very briefly in only one article [START_REF] Bhatti | Visual Tool for Teaching Synchronization in Operating Systems[END_REF], and its development seems to have stopped since then. Moreover, another tool with the same name exists, oriented towards a whole operating system graphical simulation, which is not usable for our purposes. Another project, Convit [START_REF] Järvinen | Convit, a Tool for Learning Concurrent Programming[END_REF] is a Java applet like our simulator. It can be used to ensure easy maintenance and a lightweight set-up. It allows students to test their solutions to various problems. It provides means to debug, simulate and to change the source code, such as the global deadlocks detection. However, the teacher should create all examples and interactive problems, since this supposes compiling the concurrent program parts code into Java. The Convit programming language, even if it is simple, remains a high level language. It is a mix of Pascal and C. However, Convit lacks the explanation feature of our simulator, recognized by our students as very important in understanding why and where their code has failed.

CONCLUSION

More than 400 of our students have been using our pedagogical simulator for 2 years. They have given us a very positive feedback on it. They massively ask for its extension to more complex cases, such as consumer-producer pairs, or rendezvous. As mentioned earlier, this capacity is one of its key features, since it presents an open instruction library, and uses an analysis and explanation sequence building algorithm able to cope with more than one semaphore, or more than two processes. Moreover, we intend to upgrade the diagnosis algorithm to detect all cases of starvation (i.e. when all or part of a code cannot be executed due to a lack of a SIGNAL), and we intend to include deadlock detection. It can be also enhanced to work on higher level languages, as soon as these can be compiled into instructions of our pedagogical processor.

Figure 1 .

 1 Figure 1. A step of the execution

Figure 4 .

 4 Figure 4. Impact of a process state change


Henri Delebecque
email: henri.delebecque@supelec.fr

Bich-Liên Doan
email: bich-lien.doan@supelec.fr

Yolaine Bourda Supélec

HDML: an Object-Oriented Hyper-document Descripting Meta Language for E-education

The media on which authors should publish pedagogical documents become every day more numerous, complexifying the work of either content authors, graphics designer or webmasters.

We propose an XML application for content authors, to help them structure their hypertext documents in factorizing their common structure in a class, and to free them from all the other aspects. They design both a structural model (a class), and a presentation model (using HTML, WML,…). Using these two models, our HDML engine automatically builds the projection function able to transform any actual document into (for example) well-formed web pages.

HDML also offers inheritance capabilities among classes, which allows an editor responsible for a whole document set to define its global structure, and to adapt it according to the different document sections needs.

CONTEXT 1.1 Hyper Document Structuring Language

XML can be used for the definition of a hypertext document structuring language like HDSL (Delebecque 2002), with multiple benefits:

• ability to add semantics to structural elements,

• factorization of the structure common to a document set in a structural model (the class),

• clear separation between content and presentation, using a presentation model for each presentation medium, • ability to maintain a coherent look-and-feel all through the document set, on all media

Why Object Orientation in HDML

The inheritance feature object-oriented languages define increases the power of a document class definition in allowing:

• factorization between structural models,

• customization of a general (e.g. book-wide) structure into a more precise (e.g. author-specific) one,

• specification of the operations applied to a specific document or element.

HDML General definition

HDML stands for "Hyperdocument Description Meta-Language". HDML's goal is to give content authors the ability to focus on content and ignore presentation, while using their favorite editing tools. HDML is clearly a meta-language, since it allows the class designer to define a markup language that will be used for writing documents in the content authors domain. This language definition can be considered an instantiation of HDML in this specific language, that we will call the content authoring language.

PRINCIPLES

HDML can be used by authors in three different ways, while defining three kinds of documents, which are:

• the class (the structural model),

• the presentation model,

• the concrete document (a class instance).

The class designer, who is also the whole pedagogical document editor, defines the structural model common to all the site documents. The graphic designer, or the ergonomist, designs the look-and-feel used to display these structural elements in a specific presentation medium in a presentation model. Lastly, the content author instantiates the class in concrete documents.

The HDML engine works in two stages, using the three different kinds of documents described earlier. To allow for the separation of semantics and presentation, the "Holy Grail" of XML, we propose a global lightweight framework working with pairs of documents. For every subset of the global pedagogical document (book, chapter, section…) which may or may not have its own look-and-feel, the document editor supplies a class using HDML, and the graphic designer a presentation model for each presentation medium.

Our HDML engine takes all these pairs of models and then automatically generates as many XSLT stylesheets as needed to produce "displayable" forms of the concrete HDML documents in the various presentation media forms. Thus, every XSLT style-sheet can be considered a projection function from the class to the presentation model. Subsequently this projection function is applied to the concrete documents that conform to the class structure, producing the published documents. These later documents can of course include additional items (e.g. background, logo…) provided by the presentation model.

INHERITANCE IN HDML

A document family definition can itself be derived from another wider family. This is useful for example if the former is a chapter of the book described by the later, or the web pages of a chapter in the web pages of a whole course. XML Schema provides a simple but useful inheritance feature among types (Davidson et al. 1999). HDML goes much further.

Structural Inheritance

A class can inherit its structure from another class, which in turn can inherit from another, as many times as required. In this case, we call the class inheriting a subclass, and the set of classes from which the subclass inherits the superclasses, as in object-oriented languages. The subclass can add new elements, replace (overload) or delete some elements one of the superclasses defines.

This deletion capability can have multiple practical applications. First, it will simplify the authoring task, by removing useless structural parts. The content author can thus focus on the elements relevant for him. Lastly, it increases the global document coherency by insuring its editor that critical element values (such as the version, date…) are hidden from content authors, and thus not modified in concrete documents. At the same time, HDML proposes a locking feature to the class designer, to prevent the deletion of mandatory elements in a subclass.

Behavioral Inheritance

The concept of method, familiar in object-oriented languages, could seem strange in HDML, due to its lack of programming features. Let us define it by analogy: we know some obvious operations that can be applied to documents, for example, the document initialization, or projection into a presentation medium (using an adapted presentation model).

The class designer can define a special element behavior with a method. Using this feature, he can initialize or project an element in a different manner than another, even of the same kind. This feature could be used, for example, to display the exercise answer only after the third student guess. More generally, the author can control the published information, even at the finest level, with minimal cost since this kind of information can be easily factorized in the class.

The ability to define an element method is also useful for splitting the HDML engine projection output stream into separate documents. The HDML engine is intended to take one content document, and to transform it into a "displayable" document. In many cases, this one-to-one association is not suited to the presentation medium, since the granularity of content authoring is different from the granularity of the presentation. For example, an HTML page is more or less screen-length sized, whereas the content document is more likely divided into structural entities like chapters or sections.

A document method can be defined in two different and complementary ways. The first way is that the author can overload the default behavior either in the class, or in the concrete document, for example, by specifying an instance-specific presentation model. A second way of defining a method is implicit, using inheritance. Classes inheriting their instance structure from superclasses will also inherit their instance behavior, as in object-oriented languages.

RELATED WORK

Content Management Tools

HDML is not designed to compete with commercial all-in-one content management products, like Rhythmyx, Vignette or others, even if they come from the academic world like WebML (Ceri et al. 1999), if these tools are based on proprietary formats or tools.

These products are more or less devoted to the construction of commercial web sites. Their content is often built from very dynamic information fetched from databases, and linked by complex relationships. For example, WebML uses a structural model that describes these relationships using an E/R model or an ODMG object-oriented model. There is also, as in HDML, a presentation model that defines the appearance of pages independently of the output devices and the rendering language. But WebML uses an abstract XML syntax for its definition. This option, like many others, suggests that WebML's application domain is more oriented towards e-commerce, since it requires heavy post-processing stages that HDML avoids.

HDML is mainly an open and lightweight tool, designed to keep users in their favorite environment. A major effort has been made to push its versatility at the syntax and operational levels and also to improve its importing and exporting capabilities.

Document Structuring Languages

Other projects have defined document structuring languages, as XML applications or not, such as DocBook. Even if they are very good for relatively simple document authoring, they lack the advanced features HDML offers, such as inheritance and content authoring language definition. Such capabilities are of great interest in reducing the global document management cost, especially when many presentation media are involved (like paper, slide or computer-based-support one in a pedagogical context).

XSLT

The work the HDML engine does can clearly (and perhaps better) be done by a XSLT programmer, eliminating the need for HDML. We will answer that XSLT is a powerful but not intuitive language for a non-professionals, which is the case for the majority of content authors. This implies a fourth kind of knowledge the authoring team should have, very deeply involved in the design of documents published, since this XLST author must provide the link between the structural and presentation models.

BIBLIOGRAPHY

Ceri S., Fraternali P., Paraboschi S. Data-Driven One-To-One Web Site

  Generation for Data-Intensive Applications. Proc. VLDB'99 September 1999. http://webml.elet.polimi.it/webml/ Davidson A., Fuchs M.,Hedin M., Jain M., Koistinen J., Lloyd C., Maloney M., Schwarzhof K. Schema for Object-Oriented XML 2.0. http://www.w3.org/TR/NOTE-SOX Delebecque H. HDSL: An e-education Hypertext Document Structuring Language. ED-MEDIA 2002 Denver CO USA Walsh N., Muellner L. DocBook: The Definitive Guide. http://www.docbook.org/