DOCSLIB.ORG

Analysis of Threading Libraries for High Performance Computing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Analysis of Threading Libraries for High Performance Computing This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TC.2020.2970706 © 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Analysis of Threading Libraries for High Performance Computing Adrian´ Castello´ Rafael Mayo Gual Sangmin Seo Pavan Balaji Universitat Jaume I Universitat Jaume I Ground X Argonne National Laboratory Castellon´ de la Plana, Spain Castellon´ de la Plana, Spain Seoul, Korea Lemmont, USA Email: [email protected] Email: [email protected] Email: [email protected] Email: [email protected] Enrique S. Quintana-Ort´ı Antonio J. Pena˜ Universitat Politecnica` de Valencia` Barcelona Supercomputing Center (BSC) Valencia,` Spain Barcelona, Spain Email: [email protected] Email: [email protected] Abstract—With the appearance of multi-/many core machines, of hardware parallelism may be inefficient. In response to applications and runtime systems evolved in order to exploit the this problem, dynamic scheduling and lightweight threads new on-node concurrency brought by new software paradigms. (LWTs) (also known as user-level threads, or ULTs) models POSIX threads (Pthreads) was widely-adopted for that purpose were first proposed in [5] in order to deal with the required and it remains as the most used threading solution in current levels of parallelism, offering more efficient management, hardware. Lightweight thread (LWT) libraries emerged as an alternative offering lighter mechanisms to tackle the massive context switching and synchronization operations. These concurrency of current hardware. In this paper, we analyze thread solutions rely on threads that are managed in the user- in detail the most representative threading libraries including space so that the OS is only minimally involved and, hence, Pthread- and LWT-based solutions. In addition, to examine the overhead is lower. the suitability of LWTs for different use cases, we develop To illustrate this, Figure 1 highlights the time spent when a set of microbenchmarks consisting of OpenMP patterns commonly found in current parallel codes, and we compare the creating OS thread and user-level threads (ULTs). In this results using threading libraries and OpenMP implementations. example, one thread is created for each core in a machine Moreover, we study the semantics offered by threading libraries with two Intel Xeon E5-2695v4 (2.10 GHz) CPUs and 128 in order to expose the similarities among different LWT ap- GB of memory. For the OS threads, we employ the GNU C plication programming interfaces and their advantages over 6.1 library [6], and Argobots (07-2018) threads for the ULT Pthreads. This study exposes that LWT libraries outperform case [7]. The time difference is caused by the implication of solutions based on operating system threads when tasks and the OS and by the features of each type of thread. nested parallelism are required. 0.14 Index Terms—Lightweight Threads, OpenMP, GLT, POSIX OS Threads, Programming Models ULT 0.12 1. Introduction 0.1 In the past few years, the number of cores per processor has increased steadily, reaching impressive counts such as 0.08 the 260 cores per socket in the Sunway TaihuLight su- 0.06 percomputer [1], which was ranked #1 for the first time Time (ms) in the June 2016 TOP500 list [2]. This trend indicates 0.04 that upcoming exascale systems may well feature a large 0.02 number of cores. Therefore, future applications will have to accommodate this massive concurrency by deploying a 0 1 2 4 8 16 18 32 36 40 48 64 72 large number of threads and/or tasks in order to extract # of Threads a significant fraction of the computational power of such hardware. Figure 1: Cost of creating OS threads and ULTs. Current solutions for extracting on-node parallelism are For tackling the OS overhead, a number of LWT li- based on operating system (OS) threads in both low- or high- braries have been implemented for specific OSs, such as level libraries. Examples of this usage are Pthreads [3] Windows Fibers [8] and Solaris Threads [9]; for for the former and programming models (PMs) such as specific hardware such as TiNy-threads [10] for the OpenMP [4] for the latter. However, performing thread Cyclops64 cellular architecture; or for network services such management in the OS increases the cost of these operations as Capriccio [11]. Other solutions emerged to support (e.g. creation, context-switch, or synchronization). As a con- specific higher-level PMs. This is the case of Converse sequence, leveraging OS threads to exploit a massive degree Threads [12] [13] for Charm++ [14]; and Nanos++ Copyright (c) 2020 IEEE. Personal use is permitted. For any other purposes, permission must be obtained from the IEEE by emailing [email protected]. This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TC.2020.2970706 LWTs [15] for task parallelism in OmpSs [16]. More- clusions. over, general-purpose solutions have emerged such as GNU Portable Threads [17], StackThreads/PM [18], 2. Threading Libraries ProtoThreads [19], MPC [20], MassiveThreads [21], In this section we describe the two types of threading Qthreads [22], and Argobots [7]. Other solutions libraries, OS threads and LWTs, that are analyzed and evalu- that abstract LWT facilities include Cilk [23], Intel ated in this paper. Moreover, we briefly present the OpenMP TBB [24], and Go [25]. In addition, solutions like PM, for which production implementations are currently Stackless Python [26] and Protothreads [19] are based on Pthreads. more focused on stackless threads. For the evaluation of the libraries, from the point of In spite of their potential performance benefits, none view of OS threads, we have selected Pthreads because of these LWT software solutions has been significantly this is a standard library that matches the current hard- adopted to date. The easier code development via directive- ware concurrency. In the case of LWTs, Qthreads and based PMs, in combination with the lack of a standard/ MassiveThreads have been selected because these are specification, hinder portability and require a considerable among the most used lightweight threading models in high- effort to translate code from one library to another. In order performance computing (HPC). In addition, Converse to tackle this situation, a common application programming Threads and Argobots were chosen because they cor- interface (API), called Generic Lightweight Threads (GLT), respond to the first (and still currently used) LWT library was presented in [27]. This API unifies LWT solutions under and the most flexible solution, respectively. Despite Go is a unique set of semantics, becoming the first step toward not HPC-oriented, we have also included it as representative a standard/specification. GLT is currently implemented on of the high-level abstracted LWT implementations. top of Qthreads, MassiveThreads, and Argobots. Prior to highlight the strengths and weaknesses of each One further step is presented in [28] and [29], where we solution, we present a summary of the most used func- explain the semantical mapping between the OpenMP and tions when programming with threads. Table 1 lists the OmpSs PMs and LWTs and implement both high-level so- nomenclature of each API for different functionality. This lutions on top of the GLT API. includes initialization and finalization functions that set up In this paper we demonstrate the usability and perfor- and destroy the threads environment, as well as the threads/ mance benefits of LWT solutions. We analyze several thread- tasklets management (creation, join and yield). ing solutions from a semantic point of view, identifying TABLE 1: Summary of the most used functions in mi- their strong and weak points. Moreover, we offer a detailed crobenchmark implementations using threads. Pth, Arg, Qth, performance study using OpenMP because of its position Mth, CTh, and Go identify the threading libraries Pthreads, as the de facto standard parallel PM for multi/many-core Argobots, Qthreads, MassiveThreads, Converse Threads, and architectures. Our results reveal that the performance of most Go, respectively. of the LWT solutions is similar and that these are as efficient Function Pth Arg Qth MTh CTh Go as OS threads in some simple scenarios, while outperforming (pthread ) (ABT ) (qthreads ) (myth ) them in many more complex cases. Init – init initialize init ConverseInit – In our previous work [30], we compared several LWT Thread create thread create fork create CthCreate go solutions and used the OpenMP PM as the baseline. In this Tasklet – task create – – CmiSyncSend – study we expand that work adding Pthreads library to Yield yield thread yield yield yield CthYield – Join join thread free readFF join – channel our semantic and functional analysis of threading libraries End – finalize finalize fini ConverseExit – in order to highlight the overhead (if any) introduced by the OpenMP implementations. The purpose of this paper is to present the first comparison of threading libraries from 2.1. Pthreads API a semantic point of view, along with a complete perfor- Pthreads [31] offers three PMs that differ in how mance evaluation that aims to demonstrate that LWTs are the threads are bound and which thread is in control. An a promising replacement for Pthreads used both as low- important agent in these PMs is the kernel scheduled entity level libraries and as the base implementation for high-level (KSE).
Load more

Recommended publications
  • The Essentials of Stackless Python Tuesday, 10 July 2007 10:00 (30 Minutes)
    EuroPython 2007 Contribution ID: 62 Type: not specified The Essentials of Stackless Python Tuesday, 10 July 2007 10:00 (30 minutes) This is a re-worked, actualized and improved version of my talk at PyCon 2007. Repeating the abstract: As a surprise for people who think they know Stackless, we present the new Stackless implementation For PyPy, which has led to a significant amount of new insight about parallel programming and its possible implementations. We will isolate the known Stackless as a special case of a general concept. This is a Stackless, not a PyPy talk. But the insights presented here would not exist without PyPy’s existance. Summary Stackless has been around for a long time now. After several versions with different goals in mind, the basic concepts of channels and tasklets turned out to be useful abstractions, and since many versions, Stackless is only ported from version to version, without fundamental changes to the principles. As some spin-off, Armin Rigo invented Greenlets at a Stackless sprint. They are some kind of coroutines and a bit of special semantics. The major benefit is that Greenlets can runon unmodified CPython. In parallel to that, the PyPy project is in its fourth year now, and one of its goals was Stackless integration as an option. And of course, Stackless has been integrated into PyPy in a very nice and elegant way, much nicer than expected. During the design of the Stackless extension to PyPy, it turned out, that tasklets, greenlets and coroutines are not that different in principle, and it was possible to base all known parallel paradigms on one simple coroutine layout, which is as minimalistic as possible.
    [Show full text]
  • Method, 224 Vs. Typing Module Types
    Index A migration metadata, 266 running migrations, 268, 269 Abstract base classes, 223 setting up a new project, 264 @abc.abstractmethod decorator, 224 using constants in migrations, 267 __subclasshook__(...) method, 224 __anext__() method, 330 vs. typing module types, 477 apd.aggregation package, 397, 516, 524 virtual subclasses, 223 clean functions (see clean functions) Actions, 560 database, 254 analysis process, 571, 572 get_data_by_deployment(...) config file, 573, 575 function, 413, 416 DataProcessor class, 561 get_data(...) function, 415 extending, 581 plot_sensor(...) function, 458 IFTTT service, 566 plotting data, 429 ingesting data, 567, 571 plotting functions, 421 logs, 567 query functions, 417 trigger, 563, 564 apd.sensors package, 106 Adafruit, 42, 486 APDSensorsError, 500 Adapter pattern, 229 DataCollectionError, 500 __aenter__() method, 331, 365 directory structure, 108 __aexit__(...) method, 331, 365 extending, 149 Aggregation process, 533 IntermittentSensorFailureError, 500 aiohttp library, 336 making releases, 141 __aiter__() method, 330 sensors script, 32, 36, 130, 147, 148, Alembic, 264 153, 155, 156, 535 ambiguous changes, 268 UserFacingCLIError, 502 creating a new revision, 265 apd.sunnyboy_solar package, 148, current version, 269 155, 173 downgrading, 268, 270 API design, 190 irreversible, migrations, 270 authentication, 190 listing migrations, 269 versioning, 240, 241, 243 merging, migrations, 269 589 © Matthew Wilkes 2020 M. Wilkes, Advanced Python Development, https://doi.org/10.1007/978-1-4842-5793-7 INDEX AssertionError,
    [Show full text]
  • Python Concurrency
    Python Concurrency Threading, parallel and GIL adventures Chris McCafferty, SunGard Global Services Overview • The free lunch is over – Herb Sutter • Concurrency – traditionally challenging • Threading • The Global Interpreter Lock (GIL) • Multiprocessing • Parallel Processing • Wrap-up – the Pythonic Way Reminder - The Free Lunch Is Over How do we get our free lunch back? • Herb Sutter’s paper at: • http://www.gotw.ca/publications/concurrency-ddj.htm • Clock speed increase is stalled but number of cores is increasing • Parallel paths of execution will reduce time to perform computationally intensive tasks • But multi-threaded development has typically been difficult and fraught with danger Threading • Use the threading module, not thread • Offers usual helpers for making concurrency a bit less risky: Threads, Locks, Semaphores… • Use logging, not print() • Don’t start a thread in module import (bad) • Careful importing from daemon threads Traditional management view of Threads Baby pile of snakes, Justin Guyer Managing Locks with ‘with’ • With keyword is your friend • (compare with the ‘with file’ idiom) import threading rlock = threading.RLock() with rlock: print "code that can only be executed while we acquire rlock" #lock is released at end of code block, regardless of exceptions Atomic Operations in Python • Some operations can be pre-empted by another thread • This can lead to bad data or deadlocks • Some languages offer constructs to help • CPython has a set of atomic operations due to the operation of something called the GIL and the way the underlying C code is implemented • This is a fortuitous implementation detail – ideally use RLocks to future-proof your code CPython Atomic Operations • reading or replacing a single instance attribute • reading or replacing a single global variable • fetching an item from a list • modifying a list in place (e.g.
    [Show full text]
  • Thread-Level Parallelism II
    Great Ideas in UC Berkeley UC Berkeley Teaching Professor Computer Architecture Professor Dan Garcia (a.k.a. Machine Structures) Bora Nikolić Thread-Level Parallelism II Garcia, Nikolić cs61c.org Languages Supporting Parallel Programming ActorScript Concurrent Pascal JoCaml Orc Ada Concurrent ML Join Oz Afnix Concurrent Haskell Java Pict Alef Curry Joule Reia Alice CUDA Joyce SALSA APL E LabVIEW Scala Axum Eiffel Limbo SISAL Chapel Erlang Linda SR Cilk Fortan 90 MultiLisp Stackless Python Clean Go Modula-3 SuperPascal Clojure Io Occam VHDL Concurrent C Janus occam-π XC Which one to pick? Garcia, Nikolić Thread-Level Parallelism II (3) Why So Many Parallel Programming Languages? § Why “intrinsics”? ú TO Intel: fix your #()&$! compiler, thanks… § It’s happening ... but ú SIMD features are continually added to compilers (Intel, gcc) ú Intense area of research ú Research progress: 20+ years to translate C into good (fast!) assembly How long to translate C into good (fast!) parallel code? • General problem is very hard to solve • Present state: specialized solutions for specific cases • Your opportunity to become famous! Garcia, Nikolić Thread-Level Parallelism II (4) Parallel Programming Languages § Number of choices is indication of ú No universal solution Needs are very problem specific ú E.g., Scientific computing/machine learning (matrix multiply) Webserver: handle many unrelated requests simultaneously Input / output: it’s all happening simultaneously! § Specialized languages for different tasks ú Some are easier to use (for some problems)
    [Show full text]
  • Uwsgi Documentation Release 1.9
    uWSGI Documentation Release 1.9 uWSGI February 08, 2016 Contents 1 Included components (updated to latest stable release)3 2 Quickstarts 5 3 Table of Contents 11 4 Tutorials 137 5 Articles 139 6 uWSGI Subsystems 141 7 Scaling with uWSGI 197 8 Securing uWSGI 217 9 Keeping an eye on your apps 223 10 Async and loop engines 231 11 Web Server support 237 12 Language support 251 13 Release Notes 317 14 Contact 359 15 Donate 361 16 Indices and tables 363 Python Module Index 365 i ii uWSGI Documentation, Release 1.9 The uWSGI project aims at developing a full stack for building (and hosting) clustered/distributed network applica- tions. Mainly targeted at the web and its standards, it has been successfully used in a lot of different contexts. Thanks to its pluggable architecture it can be extended without limits to support more platforms and languages. Cur- rently, you can write plugins in C, C++ and Objective-C. The “WSGI” part in the name is a tribute to the namesake Python standard, as it has been the first developed plugin for the project. Versatility, performance, low-resource usage and reliability are the strengths of the project (and the only rules fol- lowed). Contents 1 uWSGI Documentation, Release 1.9 2 Contents CHAPTER 1 Included components (updated to latest stable release) The Core (implements configuration, processes management, sockets creation, monitoring, logging, shared memory areas, ipc, cluster membership and the uWSGI Subscription Server) Request plugins (implement application server interfaces for various languages and platforms: WSGI, PSGI, Rack, Lua WSAPI, CGI, PHP, Go ...) Gateways (implement load balancers, proxies and routers) The Emperor (implements massive instances management and monitoring) Loop engines (implement concurrency, components can be run in preforking, threaded, asynchronous/evented and green thread/coroutine modes.
    [Show full text]
  • Goless Documentation Release 0.6.0
    goless Documentation Release 0.6.0 Rob Galanakis July 11, 2014 Contents 1 Intro 3 2 Goroutines 5 3 Channels 7 4 The select function 9 5 Exception Handling 11 6 Examples 13 7 Benchmarks 15 8 Backends 17 9 Compatibility Details 19 9.1 PyPy................................................... 19 9.2 Python 2 (CPython)........................................... 19 9.3 Python 3 (CPython)........................................... 19 9.4 Stackless Python............................................. 20 10 goless and the GIL 21 11 References 23 12 Contributing 25 13 Miscellany 27 14 Indices and tables 29 i ii goless Documentation, Release 0.6.0 • Intro • Goroutines • Channels • The select function • Exception Handling • Examples • Benchmarks • Backends • Compatibility Details • goless and the GIL • References • Contributing • Miscellany • Indices and tables Contents 1 goless Documentation, Release 0.6.0 2 Contents CHAPTER 1 Intro The goless library provides Go programming language semantics built on top of gevent, PyPy, or Stackless Python. For an example of what goless can do, here is the Go program at https://gobyexample.com/select reimplemented with goless: c1= goless.chan() c2= goless.chan() def func1(): time.sleep(1) c1.send(’one’) goless.go(func1) def func2(): time.sleep(2) c2.send(’two’) goless.go(func2) for i in range(2): case, val= goless.select([goless.rcase(c1), goless.rcase(c2)]) print(val) It is surely a testament to Go’s style that it isn’t much less Python code than Go code, but I quite like this. Don’t you? 3 goless Documentation, Release 0.6.0 4 Chapter 1. Intro CHAPTER 2 Goroutines The goless.go() function mimics Go’s goroutines by, unsurprisingly, running the routine in a tasklet/greenlet.
    [Show full text]
  • Continuations and Stackless Python
    Continuations and Stackless Python Or "How to change a Paradigm of an existing Program" Christian Tismer Virtual Photonics GmbH mailto:[email protected] Abstract 2 Continuations In this paper, an implementation of "Stackless Python" (a Python which does not keep state on the C 2.1 What is a Continuation? stack) is presented. Surprisingly, the necessary changes affect just a small number of C modules, and Many attempts to explain continuations can be found a major rewrite of the C library can be avoided. The in the literature[5-10], more or less hard to key idea in this approach is a paradigm change for the understand. The following is due to Jeremy Hylton, Python code interpreter that is not easy to understand and I like it the best. Imagine a very simple series of in the first place. Recursive interpreter calls are statements: turned into tail recursion, which allows deferring evaluation by pushing frames to the frame stack, x = 2; y = x + 1; z = x * 2 without the C stack involved. In this case, the continuation of x=2 is y=x+1; By decoupling the frame stack from the C stack, we z=x*2. You might think of the second and third now have the ability to keep references to frames and assignments as a function (forgetting about variable to do non-local jumps. This turns the frame stack into scope for the moment). That function is the a tree, and every leaf of the tree can now be a jump continuation. In essence, every single line of code has target.
    [Show full text]
  • Thread Scheduling in Multi-Core Operating Systems Redha Gouicem
    Thread Scheduling in Multi-core Operating Systems Redha Gouicem To cite this version: Redha Gouicem. Thread Scheduling in Multi-core Operating Systems. Computer Science [cs]. Sor- bonne Université, 2020. English. tel-02977242 HAL Id: tel-02977242 https://hal.archives-ouvertes.fr/tel-02977242 Submitted on 24 Oct 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Ph.D thesis in Computer Science Thread Scheduling in Multi-core Operating Systems How to Understand, Improve and Fix your Scheduler Redha GOUICEM Sorbonne Université Laboratoire d’Informatique de Paris 6 Inria Whisper Team PH.D.DEFENSE: 23 October 2020, Paris, France JURYMEMBERS: Mr. Pascal Felber, Full Professor, Université de Neuchâtel Reviewer Mr. Vivien Quéma, Full Professor, Grenoble INP (ENSIMAG) Reviewer Mr. Rachid Guerraoui, Full Professor, École Polytechnique Fédérale de Lausanne Examiner Ms. Karine Heydemann, Associate Professor, Sorbonne Université Examiner Mr. Etienne Rivière, Full Professor, University of Louvain Examiner Mr. Gilles Muller, Senior Research Scientist, Inria Advisor Mr. Julien Sopena, Associate Professor, Sorbonne Université Advisor ABSTRACT In this thesis, we address the problem of schedulers for multi-core architectures from several perspectives: design (simplicity and correct- ness), performance improvement and the development of application- specific schedulers.
    [Show full text]
  • Table of Contents
    Parallel Programming Models Lawrence Rauchwerger http://parasol.tamu.edu Table of Contents Introduction to Parallelism Introduction to Programming Models Shared Memory Programming Message Passing Programming Shared Memory Models PGAS Languages Other Programming Models 1 Acknowledgement Material in this course has been adapted from various (cited) authoritative sources Presentation has been put together with the help of Dr. Mauro Bianco, Antoniu Pop, Tim Smith and Nathan Thomas – Parasol Lab, Department of Computer Science, Texas A&M University. What Will You Get from Class Ideas about parallel processing Different approaches to parallel programming Additional material in your classnotes 2 Table of Contents Introduction to Parallelism – What is Parallelism ? What is the Goal ? Introduction to Programming Models Shared Memory Programming Message Passing Programming Shared Memory Models PGAS Languages Other Programming Models Introduction to Parallelism Sequential Computing – Single CPU executes stream of instructions. Adapted from: http://www.llnl.gov/computing/tutorials/parallel_comp 3 Introduction to Parallelism Parallel computing – Partition problem into multiple, concurrent streams of instructions. Classification Flynn’s Taxonomy (1966-now) Nowadays SISD SIMD SPMD Single Instruction Single Instruction Single Program Single Data Multiple Data Multiple Data MISD MIMD MPMD Multiple Instructions Multiple Instructions Multiple Program Single Data Multiple Data Multiple Data • Execution models impact the above programming model • Traditional computer is SISD • SIMD is data parallelism while MISD is pure task parallelism • MIMD is a mixed model (harder to program) • SPMD and MPMD are less synchronized than SIMD and MIMD • SPMD is most used model, but MPMD is becoming popular 4 Introduction to Parallelism Goal of parallel computing – Save time - reduce wall clock time.
    [Show full text]
  • Threading and GUI Issues for R
    Threading and GUI Issues for R Luke Tierney School of Statistics University of Minnesota March 5, 2001 Contents 1 Introduction 2 2 Concurrency and Parallelism 2 3 Concurrency and Dynamic State 3 3.1 Options Settings . 3 3.2 User Defined Options . 5 3.3 Devices and Par Settings . 5 3.4 Standard Connections . 6 3.5 The Context Stack . 6 3.5.1 Synchronization . 6 4 GUI Events And Blocking IO 6 4.1 UNIX Issues . 7 4.2 Win32 Issues . 7 4.3 Classic MacOS Issues . 8 4.4 Implementations To Consider . 8 4.5 A Note On Java . 8 4.6 A Strategy for GUI/IO Management . 9 4.7 A Sample Implementation . 9 5 Threads and GUI’s 10 6 Threading Design Space 11 6.1 Parallelism Through HL Threads: The MXM Options . 12 6.2 Light-Weight Threads: The XMX Options . 12 6.3 Multiple OS Threads Running One At A Time: MSS . 14 6.4 Variations on OS Threads . 14 6.5 SMS or MXS: Which To Choose? . 14 7 Light-Weight Thread Implementation 14 1 March 5, 2001 2 8 Other Issues 15 8.1 High-Level GUI Interfaces . 16 8.2 High-Level Thread Interfaces . 16 8.3 High-Level Streams Interfaces . 16 8.4 Completely Random Stuff . 16 1 Introduction This document collects some random thoughts on runtime issues relating to concurrency, threads, GUI’s and the like. Some of this is extracted from recent R-core email threads. I’ve tried to provide lots of references that might be of use.
    [Show full text]
  • Expert Python Programming Third Edition
    Expert Python Programming Third Edition Become a master in Python by learning coding best practices and advanced programming concepts in Python 3.7 Michał Jaworski Tarek Ziadé BIRMINGHAM - MUMBAI Expert Python Programming Third Edition Copyright © 2019 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. Commissioning Editor: Kunal Chaudhari Acquisition Editor: Chaitanya Nair Content Development Editor: Zeeyan Pinheiro Technical Editor: Ketan Kamble Copy Editor: Safis Editing Project Coordinator: Vaidehi Sawant Proofreader: Safis Editing Indexer: Priyanka Dhadke Graphics: Alishon Mendonsa Production Coordinator: Shraddha Falebhai First published: September 2008 Second edition: May 2016 Third edition: April 2019 Production reference: 1270419 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78980-889-6 www.packtpub.com To my beloved wife, Oliwia, for her love, inspiration, and her endless patience.
    [Show full text]
  • Kernel Threads
    CSMC 412 Operating Systems Prof. Ashok K Agrawala © 2019 Ashok Agrawala February 20 1 Threads & Concurrency Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018 Threads • Overview • Multicore Programming • Multithreading Models • Thread Libraries • Implicit Threading • Threading Issues • Operating System Examples February 20 Copyright 2018 Silberschatz, Gavin & Gagne 3 Objectives • To introduce the notion of a thread—a fundamental unit of CPU utilization that forms the basis of multithreaded computer systems • To discuss the APIs for the Pthreads, Windows, and Java thread libraries • To explore several strategies that provide implicit threading • To examine issues related to multithreaded programming • To cover operating system support for threads in Windows and Linux February 20 Copyright 2018 Silberschatz, Gavin & Gagne 4 Process PC … Address Space February 20 Copyright 2018 Silberschatz, Gavin & Gagne 5 Process Control Block (PCB) Information associated with each process (also called task control block) • Process state – running, waiting, etc • Program counter – location of instruction to next execute • CPU registers – contents of all process- centric registers • CPU scheduling information- priorities, scheduling queue pointers • Memory-management information – memory allocated to the process • Accounting information – CPU used, clock time elapsed since start, time limits • I/O status information – I/O devices allocated to process, list of open files February 20 Copyright 2018 Silberschatz, Gavin & Gagne 6
    [Show full text]