VUE3.0 をすぐに使い始める方法: ラーニング
にアクセスする場合、バッファー上で同時に操作が実行されると、リソース競合の問題が発生する可能性があります。 Atomics API を使用すると、バッファ上で一度に 1 つの操作のみを実行できるようにすることで、複数のコンテキストが SharedArrayBuffer を安全に読み書きできるようになります。
アトミック操作の性質により、オペレーティング システムやコンピューター ハードウェアが通常は自動的に実行する最適化 (命令の並べ替えなど) が不可能になります。また、アトミック操作では、メモリに同時にアクセスすることができなくなり、不適切に使用するとプログラムの実行が遅くなる可能性があります。このため、Atomics API の本来の設計目的は、最小限でありながら安定した複雑なマルチスレッド JavaScript プログラムを構築することです。アトミックな動作。
アトミックス API は、インプレース変更操作を実行するための一連の単純なメソッドを提供します。 ECMA 仕様では、これらのメソッドは AtomicReadModifyWrite オペレーションとして定義されています。これらのメソッドは内部的に、SharedArrayBuffer 内の場所から値を読み取り、算術演算およびビット単位の演算を実行し、最後に結果を同じ場所に書き込みます。これらの操作のアトミックな性質は、上記の読み取り、変更、およびライトバック操作が順番に実行され、他のスレッドによって中断されないことを意味します。
// サイズ 1 のバッファを作成します letsharedArrayBuffer = new SharedArrayBuffer(1); //バッファに基づいて Unit8Arraylet を作成します。 typedArray = new Unit8Array(sharedArrayBuffer); //すべての ArrayBuffers は 0console.log(typedArray) に初期化されます。 //ユニット8配列[0] //インデックス 0Atomics.add(typedArray,0,10); の値に 10 のアトミック加算を実行します。 //Unit8Array[10] //インデックス 0Atomics.sub(typedArray,0,10) の値に対して 10 のアトミック減算を実行します。 //Unit8Array[0]
ブラウザの JavaScript コンパイラと CPU アーキテクチャ自体は、プログラムの実行効率を向上させるために命令を再配置する権限を持っています。通常の状況では、JavaScript のシングルスレッド環境でいつでもこの最適化を実行できますが、マルチスレッドでの命令の再配置はリソースの競合を引き起こす可能性があり、トラブルシューティングが非常に困難です。
Atomics API は、主に 2 つの方法でこの問題を解決します。
すべてのアトミック命令の相互の順序が並べ替えられることはありません。
アトミックな読み取りまたは書き込みを使用すると、すべての命令がアトミックな読み取りおよび書き込みに対して並べ替えられないことが保証されます。
Atomics.load() と Atomics.store() は、バッファ値の読み取りと書き込みに加えて、「コード フェンス」を構築することもできます。 JavaScript エンジンは、非アトミックな命令を、load() および store() に関連してローカルに再配置できることを保証しますが、この再配置はアトミックな読み取りおよび書き込みの境界を侵害しません。
constsharedArrayBuffer = new SharedArrayBuffer(4); const view = new Unit32Array(sharedArrayBuffer); //非アトミックな書き込みを実行します view[0] = 1; //非アトミックな書き込みはこの読み取り操作の前に完了することが保証されているため、ここでは 1console.log(Atomics.load(view,0)); が必ず読み取られます。 //1 //アトミック書き込みを実行 Atomics.store(view,0,2); //非アトミックな読み取りはアトミックな書き込みが完了した後に発生することが保証されており、2console.log(view[0]) はここで確実に読み取られます。 //2
最初に読み取り、次に書き込みを継続的かつ中断なく行うために、Atomics API には、exchange() と CompareExchange() という 2 つのメソッドが用意されています。 Atomics.exchange() は、他のスレッドが交換を中断しないことを保証する単純な交換を実行します。
constsharedArrayBuffer = new SharedArrayBuffer(4); const view = new Unit32Array(sharedArrayBuffer); // 10Atomics.store(view,0,10) をインデックス 0 に書き込みます。 //インデックス 0 から値を読み取り、インデックス 0 に 5 を書き込みますconsole.log(Atomics.exchange(view,0,5)); //10 //インデックス 0 から値を読み取ります console.log(Atomics.load(view,0)); //5
マルチスレッド プログラムでは、最後に値が読み取られてから他のスレッドがその値を変更していない場合にのみ、スレッドが共有バッファに書き込む必要がある場合があります。値が変更されていない場合、このスレッドは更新された値を安全に書き込むことができます。値が変更されている場合、書き込み操作を実行すると、他のスレッドによって計算された値が破棄されます。この種のタスクのために、Atomics API は Compare-Exchange() メソッドを提供します。このメソッドは、ターゲット インデックスの値が期待値と一致する場合にのみ書き込み操作を実行します。
何らかのロック メカニズムがなければ、マルチスレッド プログラムは複雑な要件をサポートできません。この目的を達成するために、Atomics API は Linux Futex (高速ユーザー空間ミューテックス) を模倣するメソッドを提供します。これらのメソッドは、それ自体は非常に単純ですが、より複雑なロック メカニズムの基本コンポーネントとして機能します。
すべてのアトミックな Futex 操作は、Int32Array ビューでのみ使用でき、さらにワーカー スレッド内でのみ使用できます。
クロスドキュメント メッセージングは、XDM (クロスドキュメント メッセージング) とも呼ばれ、異なる実行コンテキスト (異なるソースの異なるワーカー スレッドやページなど) 間で情報を転送する機能です。
エンコーディング API は主に文字列とステレオタイプ配列間の変換に使用されます。
ファイル API は依然としてフォームのファイル入力フィールドに基づいていますが、ファイル情報に直接アクセスする機能が追加されています。 HTML5 では、ファイル入力要素の DOM にファイル コレクションが追加されます。ユーザーがファイル フィールドで 1 つ以上のファイルを選択すると、ファイル コレクションには、選択したファイルを表す一連の File オブジェクトが含まれます。各 File オブジェクトには、いくつかの読み取り専用属性があります。
FileReader タイプは、サーバーからデータを読み取るのではなく、ファイル システムからファイルを読み取るために使用されることを除けば、FileReader を XMLHttpRequest と同様に考えることができます。 FileReader タイプには、ファイル データを読み取るためのメソッドがいくつか用意されています。
readAsText(file,encoding);//ファイルからプレーンテキストコンテンツを読み取り、結果属性に保存します
readAsDataURL(file);//ファイルを読み取り、コンテンツのデータ URI を結果属性に保存します
readAsBinaryString(file); / / ファイルを読み取り、各文字のバイナリ データを結果属性に保存します。
readAsArrayBuffer(file); // ファイルを読み取り、ファイルの内容を ArrayBuffer の形式で結果属性に保存します
タイプファイルリーダーのタイプ。
場合によっては、ファイル全体ではなくファイルの一部を読み取る必要がある場合があります。このために、File オブジェクトには、slice() というメソッドが用意されています。 lice() メソッドは、開始バイトと Yaodu 領域のバイト数の 2 つのパラメータを受け取ります。このメソッドは、実際には File のスーパークラスである Blob のインスタンスを返します。
Blob はバイナリ ラージ オブジェクトを表します。これは、変更不可能なバイナリ データに対する JavaScript のカプセル化タイプです。文字列を含む配列、ArrayBuffers、ArrayBufferView、さらにはその他の BLOB を使用して BLOB を作成できます。 Blob コンストラクターはオプション パラメーターを受け取り、その中で MIME タイプを指定できます。
Streams API は、単純だが基本的な問題、つまり Web アプリケーションが大きな情報ブロックではなく、順序付けられた小さな情報ブロックをどのように消費するのかを解決するために生まれました。この機能には、主に 2 つのアプリケーション シナリオがあります。
Streams API は 3 つのストリームを定義します。
読み取り可能なストリーム: パブリック インターフェイスを通じてデータ ブロックを読み取ることができるストリーム。データは基礎となるソースから内部的にストリームに入り、コンシューマによって処理されます。
書き込み可能なストリーム: 何らかのパブリック インターフェイスを介してデータのブロックを書き込むことができるストリーム。プロデューサー (コンシューマー) はデータをストリームに書き込み、データは内部で基礎となるデータ スロット (シンク) に転送されます。
変換ストリーム: 2 つのストリームで構成されます。書き込み可能ストリームはデータの受信に使用され、読み取り可能ストリームはデータの出力に使用されます。これら 2 つのストリーム品質チェックは、必要に応じてストリーム コンテンツを検査および変更できるトランスフォーマーです。
Web 暗号化 API は、JavaScript が安全かつ従来の方法で暗号化を実装する方法を標準化する一連の暗号化ツールを記述します。これらのツールには、暗号化キー ペアの生成、使用、適用、情報の暗号化と復号化、および乱数の信頼性の高い生成が含まれます。
乱数を生成する必要がある場合、多くの人がMath.random()を使用します。このメソッドは、疑似乱数ジェネレーター (PRNG、PseudoRandom Number Generator) としてブラウザーに実装されます。いわゆる擬似とは、真にはランダムではない値を生成するプロセスを指します。 PRNG によって生成された値は、ランダムな特性のみをシミュレートします。ブラウザの PRNG は真のランダム ソースを使用せず、固定アルゴリズムを内部状態に適用するだけです。 Math.random()が呼び出されるたびに、この内部状態がアルゴリズムによって変更され、結果が新しい乱数に変換されます。たとえば、V8 エンジンは、 xorshift128+と呼ばれるアルゴリズムを使用してこの変更を実行します。
アルゴリズム自体は固定されており、その入力は前の状態のみであるため、乱数列も決定されます。 xorshift128+ 128 ビットの内部状態を使用し、アルゴリズムは、初期状態が繰り返される前に 2 128 -1 の擬似乱数値を生成するように設計されています。この種のループは順列ループと呼ばれ、このループの長さは周期と呼ばれます。攻撃者が PRNG の内部状態を知っていれば、その後に生成される擬似乱数値を予測できることは明らかです。開発者が誤って PRNG を使用して暗号化用の秘密キーを生成した場合、攻撃者は PRNG のこの機能を使用して秘密キーを計算する可能性があります。
擬似乱数ジェネレーターは主に一見乱数を迅速に計算するために使用されますが、暗号化アルゴリズムには適していません。この問題を解決するには、暗号的に安全な擬似乱数ジェネレーター (CSPRNG、Cryptographically Secure PseudoRandom Number Generator) を使用し、さらにエントロピーを追加します。予測不可能な動作を伴うハードウェア時間やその他のシステム特性のテストなどの入力では、PRNG ほど高速ではありませんが、生成された値は予測が難しく、暗号化に使用できます。
Web 暗号化 API には CSPRNG が導入されており、 crypto.getRandomValues()を通じてグローバルCryptoオブジェクトにアクセスできます。 0 から 1 までの浮動小数点数を返すMath.random()とは異なり、 getRandomValues()パラメータとして渡されたステレオタイプ化された配列にランダムな値を書き込みます。基礎となるバッファーにはランダムなビットが埋め込まれるため、ステレオタイプ化された配列のクラスは重要ではありません。
