BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Multi-threading に関するすべてのコンテンツ

  • JDK 21の構造化並行処理:並行プログラミングの飛躍的な進歩

    JEP 453「構造化同時実行(プレビュー)」は、JDK 21のTargetedステータスから統合された。以前はインキュベートAPIであったが、この最初のプレビューでは、過去2回のインキュベートからのフィードバックに対応した機能強化が盛り込まれている。JEP 428「構造化同時実行(インキュベーター」(JDK 19で提供)、JEP 437「構造化同時実行(セカンドインキュベーター)」(JDK 20で提供)。現在の提案における唯一の重要な変更は、StructuredTaskScope::fork(...)メソッドがFutureではなくSubtaskを返すということである。これはプレビュー機能である。

  • JEP 428: javaマルチスレッドプログラミングを容易にする構造化並行性

    JEP 428 "Structured Concurrency (Incubator)"が、JDK 19のProposed to TargetステータスからTargetedステータスに昇格した。Project Loomの傘下にあるこのJEPは、異なるスレッド上で動作する複数のタスクをアトミックなオペレーションとして扱うライブラリの導入によって、マルチスレッドプログラミングを簡略にすることを提案するものだ。エラー処理の容易化、信頼性の向上、可観測性の改善が期待できる。

  • .NET 6: スレッドの改善

    非同期や並列プログラミングの複雑さを抽象化するために多数のライブラリが存在するが、それでも開発者は、時々、下位のスレッド処理ロジックへの落とし込みが必要になる。.NET6シリーズのAPIの変更に続いて、マルチスレッドのいくつかの新しい効果的な方法を見ていこう。

  • Netflix Zuulが、非同期なノンブロッキングアーキテクチャに大変身

    Rags Srinivas氏は、マイクロサービス向けのZuulゲートウェイの主要な再構築についてNetflixのエンジニアリングマネージャーであるMikey Cohen氏に話を聞いた。 Cohen氏はその旅路について話し、この重要な試みの動機とチャレンジに話題を進める。

  • Gil Tene氏が講演でハードウェアトランザクショナルメモリを解説

    QCon New York 2016で行なわれたプレゼンテーション “Understanding Hardware Transactional Memory”で,Gil Tene氏は,ハードウェアトランザクショナルメモリ(HTM)について紹介した。概念としては古くからあったものの,やっと今,一般的なハードウェアとして利用できるようになったHTMの目的は,メモリの複数アドレスに対するアトミックな書き込みを可能にして,他のスレッドとの共同動作に矛盾を生じさせないことだ。

  • FacebookのAsyncDisplayKit - iOSアプリ用のスムーズな非同期UIが特徴

    FacebookがAsyncDisplayKitをオープンソースとして公開した。元々は,旧型のデバイス上でもアプリのスムーズな動作と応答性の維持を容易に保証する目的で,同社のPaperアプリのために開発されたフレームワークだったものだ。

  • .NETが不変になる

    .NETの開発でよく誤解されるのは、IEnumerable型やReadOnlyCollection型の変数がスレッドセーフだという考え方だ。IEnumerableやReadOnlyCollectionを使いたくなるようなシナリオで、真にスレッドセーフなコレクションを提供するために、MicrosoftのBase Class Library (BCL) チームは、新しい不変コレクションのプレビューを提供している。

  • NETのデッドロックを検出するPostSharp

    SharpCraftersのAOPフレームワークの開発元であるPostSharpは、デッドロック検出ツールを開発した。このツールはMutex、Monitor、ReaderWriterLockのような一般的なロックプリミティブを用いて、単一の行をプロジェクトに追加するだけで利用できる。

  • Vector Fabrics、マルチコアソフトウェア最適化のためのPareonを発表

    オランダのVector FabricsがPareonというツールを発表した。プレスリリースによると、このツールを使えばアプリケーションをマルチコアシステム向けに最適化できるという。

  • マルチスレッドとWPF 4.5

    WPF 4.5ではマルチスレッド・データバインディングのサポートが改善されたが、このテクニックには依然としてリスクがある。この記事では、それがどのように動いているか、安全に使うには何が必要かについて説明する。

  • なぜMicrosoftはVBとC#に非同期シンタックスが必要と信じるのか。

    VBとC#の新しい非同期CPTを見ると、実際に中核言語に組込まれたように見える。しかし、マルチコア システムを重要視して、なぜMicrosoftは、特に単一スレッドの非同期プログラミングを簡単にするように設計したシンタックスに、そんなにも投資するのだろうか?

  • C# 4.0によるデッドロックの問題の「解決」

    同じソースコードの最適化されたビルドと最適化されていないビルドは、それぞれ異なるデッドロックになる可能性があることを、数年前Eric Lippert氏は述べた。

  • Concurrent Basic – メッセージベースの並行性の宣言型言語

    Concurrent Basicは、見込まれるVisual Basicの将来を表す。Polyphonic C#およびC-OmegaなどのC#研究言語で実行される作業に基づいているけれども、Visual Basicは宣言型プログラミングの本来備わっている傾向のため、白羽の矢が立った。その構文は、VBの宣言型イベントハンドラによって着想される。

  • より優れたスレッドセーフなコレクションの構築

    スレッドセーフなコレクションには大抵いくつかの根本的な問題がある。個々の操作がスレッドセーフである一方、大抵の場合それらの操作は結合可能ではない。スタックの先頭にある要素をポップする前に要素数を調べる、といったような一般的な操作は本質的には危険である。例えば .NET 4 の Coordination Data Structuresなどのように振る舞いの結合を図る API は存在するものの、それは TryDequeue のような不格好なメソッドにつながる。

  • ThreadPoolがTask、ContinuationおよびFutureに取って代わる

    .NET 4.0で、スレッドプールの新バージョンが利用可能になる。パフォーマンスおよびロードバランシングの拡張機能に加えて、この新たなスレッドプールはTaskの使用を可能にする。

BT