Null safety trong Flutter

1. Null safety là gì

a. Tổng quan về null safety

• Trong các ngôn ngữ lập trình hướng đối tượng có một lỗi mà chúng ta rất hay gặp đó là NullPointerException, lỗi này có thể dẫn đến việc ứng dụng bị crash, ảnh hưởng đến trải nghiệm người dùng.
• Để có thể giúp cho lập trình viên quản lý được việc nullable của một đối tượng từ đó từ khóa null safety xuất hiện.
• Null safety cho phép bạn chỉ định việc một đối tượng có thể null hay không ngay từ khi khởi tạo. Và khi bạn muốn dùng nó compiler sẽ nhắc cho bạn để bạn có thể xử lý các exception liên quan đến việc biến có thể bị null

b. Null safety trong Flutter và Dart

• Null safety bắt đầu có từ phiên bản Dart 2.12 và Flutter 2
• Ở trạng thái mặc định những biến của bạn sẽ ở trạng thái non-nullable, điều đó có nghĩa là nó không thể null trừ khi bạn cho phép nó có thể. Với null safety các lỗi liên quan đến null sẽ chuyển từ các lỗi trong quá trình chạy thành các lỗi trong quá trình viết code. Điều này tránh những sai sót không đáng có trong quá trình chạy ứng dụng.
• Trình biên dịch Dart có thể tối ưu hóa code, điều sẽ giúp cho project nhỏ hơn và chạy nhanh hơn.

Từ đó chúng ta có bài toán migrate những source code đã được viết trước phiên bản có null safety và biến nó thành source code có sử dụng null safety

2. Cách migrate từ source code không có null safety

a. Migrate code theo một thứ tự

• Nếu chúng ta có sử dụng nhiều package, chúng ta nên lần lượt migrate chúng theo một thứ tự từ package được sử dụng nhiều nhất trong các package khác trước

b. Các bước migrate code sử dụng tool

• Để demo cho phần này chúng ta sử dụng một class User

class User {
  String name;
  int age;
  int yearOfBirth;
  String des;
  User({this.name, this.age});

  set setCalculate(int cal){
    yearOfBirth = cal;
  }
}

Phiên bản của Dart

sdk: ‘>=2.10.0 <3.0.0'

• Để bắt đầu chúng ta kiểm tra phiên bản của dart, hãy đảm bảo rằng bạn đang sử dụng phiên bản mới nhất của Dart SDK

dart --version

• Tiếp theo là kiểm tra trạng thái của các dependency

dart pub outdated --mode=null-safety

Nếu output hiển thị ra như hình dưới đây thì bạn sẽ phải update các dependency

• Sử dụng tool để migrate code

Trước khi bắt đầu migrate chúng ta cần biết về một vài hint marker – những thứ sẽ giúp chúng ta đánh dấu null safety cho các biến.

Chúng ta sử dụng lệnh sau ở terminal để bắt đầu quá trình migrate:

dart migrate

Sau một thời gian sẽ có một đường link dẫn đến tool migration, giao diện như sau:

Đến đây chúng ta sẽ bắt đầu dùng những hint marker vào những chỗ được gợi ý dùng

Ở đây chúng ta mong muốn 3 biến name, age, yearOfBirth đều là non-nullable, vì vậy chúng ta thêm /*!*/ vào các biến đó, biến des có thể null vậy chúng ta thêm /*?*/.

Để tiến hành xem các thay đổi chúng ta ấn nút Rerun with changes, những thay đổi sẽ có trong code sau khi được migrate sẽ hiện ra

Giải thích:

• Hai biến name và age được đánh dấu non-nullable, và được đặt trong cặp dấu ‘{}’ trong constructor, vì vậy từ khóa ‘required’ sẽ được thêm vào để yêu cầu giá trị init cho chúng khi đối tượng User mới được khởi tạo
• Biến yearOfBirth được đánh dấu là non-nullable, tuy nhiên không xuất hiện trong constructor, vì vậy sẽ có thêm từ khóa ‘late’ từ khóa này
• Biến des được đánh dấu là nullable do biến đó có thể null.

Sau khi kết thúc quá trình migration, chúng ta ấn nút ‘Apply migration’ để những thay đổi đó xuất hiện trên code của chúng ta

class User {
  String name;
  int age;
  late int yearOfBirth;
  String? des;
  User({required this.name, required this.age});

  set setCalculate(int cal){
    yearOfBirth = cal;
  }
}

Trên đây là code của lớp User sau khi được migrate

Cùng với sự thay đổi ở code, phiên bản của Dart cũng đã được update

sdk: ‘>=2.12.0 <3.0.0'

Đến đây là chúng ta đã hoàn thành quá trình migrate một đoạn code Dart sang null safety

Việc apply null safety đem lại rất nhiều lợi ích cho code của bạn, ngoài việc bắt kịp về mặt công nghệ nó còn giúp code của bạn an toàn hơn, chạy nhanh hơn.

Tham khảo

• Sound null safety | Dart
• Migrating to null safety | Dart

Theo nghĩa rộng nhất có thể, trạng thái của ứng dụng là mọi thứ tồn tại trong bộ nhớ khi ứng dụng đang chạy. Điều này bao gồm nội dung của ứng dụng, tất cả các biến mà khung Flutter lưu giữ về giao diện người dùng, trạng thái hoạt ảnh, kết cấu, phông chữ, v.v. Mặc dù định nghĩa rộng nhất có thể này về trạng thái là hợp lệ, nhưng nó không hữu ích lắm cho việc kiến trúc một ứng dụng.

Đầu tiên, bạn thậm chí không quản lý một số trạng thái (như kết cấu). Khung xử lý những điều đó cho bạn. Vì vậy, một định nghĩa hữu ích hơn về trạng thái là “bất kỳ dữ liệu nào bạn cần để xây dựng lại giao diện người dùng của bạn bất kỳ lúc nào”. Thứ hai, trạng thái mà bạn tự quản lý có thể được tách thành hai loại khái niệm: ephemeral state and app state.

Ephemeral state

Ephemeral state (đôi khi được gọi là UI state or local state) là trạng thái bạn có thể chứa gọn gàng trong một tiện ích con.

Đây là một định nghĩa mơ hồ, vì vậy đây là một vài ví dụ:

• Page hiện tại trong PageView
• Tiến hành hiện tại trong một animation phức tạp.
• Tab được chọn hiện tại trong BottomNavigationBar.

Các phần khác của widget tree hiếm khi cần phải truy cập vào loại trạng thái này. Không cần phải tuần tự hóa nó và nó không thay đổi theo những cách phức tạp.

Nói cách khác, không cần sử dụng các kỹ thuật quản lý trạng thái (ScopedModel, Redux, v.v.) trên loại trạng thái này. Tất cả những gì bạn cần là một StatefulWidget.

Dưới đây, bạn thấy cách mục hiện được chọn trong thanh điều hướng dưới cùng được giữ trong trường _index của lớp _MyHomepageState. Trong ví dụ này, _index là ephemeral state.

Ở đây, việc sử dụng setState() và một trường bên trong lớp StatefulWidget’s State là hoàn toàn tự nhiên. Không phần nào khác trong ứng dụng của bạn cần truy cập _index. Biến chỉ thay đổi bên trong tiện ích MyHomepage. Và, nếu người dùng đóng và khởi động lại ứng dụng, bạn đừng bận tâm rằng _index đặt lại về 0.

App state

Đây không phải là ephemeral state mà bạn muốn chia sẻ trên nhiều phần của ứng dụng và bạn muốn giữ lại giữa các phiên của người dùng, chúng ta gọi là application state (đôi khi còn được gọi shared state).

Ví dụ về application state:

• Sở thích của người sử dụng
• Thông tin đăng nhập
• Thông báo trong một ứng dụng mạng xã hội
• Giỏ hàng trong ứng dụng thương mại điện tử
• Trạng thái đã đọc / chưa đọc của các bài báo trong một ứng dụng tin tức

Để quản lý app state, bạn sẽ muốn nghiên cứu các tùy chọn của mình. Lựa chọn của bạn phụ thuộc vào mức độ phức tạp và bản chất của ứng dụng, trải nghiệm trước đây của nhóm bạn và nhiều khía cạnh khác.

Không có quy tắc rõ ràng.

Để rõ ràng hơn, bạn có thể sử dụng State và setState() để quản lý tất cả các trạng thái trong ứng dụng của mình. Trên thực tế, nhóm Flutter thực hiện điều này trong nhiều mẫu ứng dụng đơn giản (bao gồm cả ứng dụng dành cho người mới bắt đầu mà bạn nhận được sau mỗi lần tạo Flutter).

Nó cũng đi theo hướng khác. Ví dụ: bạn có thể quyết định rằng — trong ngữ cảnh của ứng dụng cụ thể của bạn — tab đã chọn trong thanh điều hướng dưới cùng không phải là trạng thái tạm thời. Bạn có thể cần phải thay đổi nó từ bên ngoài lớp học, giữ nó giữa các phiên, v.v. Trong trường hợp đó, biến _index là trạng thái ứng dụng.

Không có quy tắc chung, rõ ràng nào để phân biệt một biến cụ thể là ephemeral sate hay trạng thái ứng dụng. Đôi khi, bạn sẽ phải cấu trúc lại cái này thành cái khác. Ví dụ: bạn sẽ bắt đầu với một số trạng thái rõ ràng là tạm thời, nhưng khi ứng dụng của bạn phát triển về các tính năng, nó có thể cần được chuyển sang app state.

Vì lý do đó, hãy lấy sơ đồ sau với một lượng muối lớn:

Cảm ơn mọi người đã theo dõi.

Để hiểu điều này trước tiên chúng ta hãy hiểu Stateful Builder là gì?

StatefulBuilder là một widget có trạng thái có thể thay đổi (trạng thái có thể thay đổi), điều làm cho nó trở nên đặc biệt là chỉ xây dựng lại widget cụ thể được bao bọc trong Stateful Builder. Rất may là không có việc xây dựng lại toàn bộ widget, không có vấn đề gì widget được bao bọc trong Stateful Builder nằm trong Stateless hay stateful Widget.

Bây giờ câu hỏi đặt ra là chúng ta biết rằng nó không thể xây dựng lại Stateless Widget cho đến khi có một phiên bản mới. (SetState không hoạt động)

Stateful builder có sức mạnh của StateSetter chức năng được truyền cho trình xây dựng được sử dụng để gọi một quá trình xây dựng lại chính nó thay vì một trạng thái điển hình của toàn bộ Widget.

StatefulBuilder(
builder: (BuildContext context, StateSetter setState) => Checkbox(
  value: isChecked,
  onChanged: (value) {
    setState(() {
      isChecked = value;
    });
  },
),
),

GHI NHỚ

Bất kỳ biến nào đại diện cho trạng thái nên được giữ bên ngoài hàm build có nghĩa là Bạn phải khai báo biến bên ngoài phương thức build để thay đổi xảy ra.

Như tôi đã đề cập ở trên, nó chỉ xây dựng lại một widget cụ thể. Nó chỉ cung cấp một thể hiện mới (State) cho widget cụ thể đó. vì vậy bạn đã gói tất cả widget (chế độ xem) mà bạn muốn thấy sự thay đổi trong StatefulBuilder.

Để hiểu Tại sao Stateful Builder không thể thay thế một Stateful widget. Đầu tiên chúng ta hãy hiểu điều gì tạo nên sự khác biệt giữa Widget không trạng thái và Widget trạng thái.

Bạn có nhận thấy trong phương pháp xây dựng ghi đè không trạng thái và mặt khác trong tiện ích con Stateful trước tiên sẽ ghi đè createState và sau đó ghi đè phương thức build? Điều xảy ra ngầm là khi widget không trạng thái nhận được một phiên bản mà hàm xây dựng của nó được gọi. và trong widget trạng thái trước tiên, hãy tạo thể hiện trạng thái để xây dựng hàm.Đó là cách setState đang hoạt động. Sau khi chạy setState, createState đưa ra một thể hiện mới để xây dựng lại phương thức và tiện ích con.

Giờ chúng ta sẽ hiểu tại sao Stateful Builder không thể thay thế tiện ích Stateful.

Nếu nó đang xây dựng lại phần cụ thể của cây widget. Tại sao chúng ta không thể sử dụng thay thế cho Stateful Widget?

Nếu bạn lưu trữ bất kỳ trạng thái nào trong các biến cá thể trong widget không trạng thái, nó có thể bị mất bất cứ lúc nào vì hàm tạo cho widget không trạng thái có thể được gọi lặp lại, giống như phương thức build. Chỉ có Trạng thái phiên bản liên quan của tiện ích con Stateful được lưu giữ bởi Flutter.

StatefulWidget vẫn được giữ nguyên trạng thái của nó ngay cả trong các lần xây dựng lại, đó là lý do tại sao đôi khi bạn thấy các hoạt động sai của TextEditorController trong Stateless Widget

Hoặc nếu bạn không đủ khả năng sử dụng StatefulBuilder với Stateless Widget thì bạn phải lưu trạng thái bằng các khóa Toàn cục.

Cảm ơn bạn đã đọc bài viết này nếu bạn thấy bất cứ điều gì có thể được cải thiện, vui lòng cho tôi biết, tôi rất muốn cải thiện.

Ví dụ.

Để minh họa, hãy xem xét ứng dụng đơn giản sau.

Ứng dụng có hai màn hình riêng biệt: danh mục và giỏ hàng (được đại diện bởi các tiện ích MyCatalog và MyCart, tương ứng). Nó có thể là một ứng dụng mua sắm, nhưng bạn có thể tưởng tượng cấu trúc tương tự trong một ứng dụng mạng xã hội đơn giản (thay thế danh mục cho “tường” và giỏ hàng cho “yêu thích”).

Màn hình danh mục bao gồm thanh ứng dụng tùy chỉnh (MyAppBar) và dạng xem cuộn của nhiều mục danh sách (MyListItems).

Đây là ứng dụng được hình dung dưới dạng cây tiện ích con.

Vì vậy, chúng ta có ít nhất 5 lớp con của Widget. Nhiều người trong số họ cần quyền truy cập vào trạng thái “thuộc về” ở nơi khác. Ví dụ: mỗi MyListItem cần có khả năng tự thêm vào giỏ hàng. Nó cũng có thể muốn xem liệu mặt hàng được hiển thị hiện đã có trong giỏ hàng hay chưa.

Điều này đưa chúng ta đến câu hỏi đầu tiên: chúng ta nên đặt trạng thái hiện tại của giỏ hàng ở đâu?

Đưa trạng thái lên

Trong Flutter, bạn nên giữ trạng thái ở trên các widget sử dụng nó.

Tại sao? Trong các khung công tác khai báo như Flutter, nếu bạn muốn thay đổi giao diện người dùng, bạn phải xây dựng lại nó. Không có cách nào dễ dàng để có MyCart.updateWith (somethingNew). Nói cách khác, thật khó để thay đổi thứ bậc một tiện ích từ bên ngoài, bằng cách gọi một phương thức trên đó. Và ngay cả khi bạn có thể làm cho điều này thành công, bạn sẽ chiến đấu với khuôn khổ thay vì để nó giúp bạn.

Ngay cả khi code trên hoạt động, bạn sẽ phải xử lý những điều sau trong tiện ích MyCart:

Bạn sẽ cần phải xem xét trạng thái hiện tại của giao diện người dùng và áp dụng dữ liệu mới cho nó. Thật khó để tránh lỗi theo cách này.

Trong Flutter, bạn tạo một widget mới mỗi khi nội dung của nó thay đổi. Thay vì MyCart.updateWith (somethingNew) (một cuộc gọi phương thức), bạn sử dụng MyCart (nội dung) (một phương thức khởi tạo). Vì bạn chỉ có thể tạo các tiện ích con mới trong các phương pháp tạo của cha mẹ chúng, nên nếu bạn muốn thay đổi nội dung, tiện ích con đó phải ở chế độ gốc của MyCart trở lên.

Bây giờ MyCart chỉ có một đường dẫn mã để xây dựng bất kỳ phiên bản giao diện người dùng nào.

Trong ví dụ của chúng ta, nội dung cần phải tồn tại trong MyApp. Bất cứ khi nào nó thay đổi, nó sẽ xây dựng lại MyCart từ bên trên (sẽ nói thêm về điều đó sau). Do đó, MyCart không cần phải lo lắng về vòng đời — nó chỉ khai báo những gì sẽ hiển thị cho bất kỳ nội dung nhất định nào. Khi điều đó thay đổi, tiện ích MyCart cũ sẽ biến mất và được thay thế hoàn toàn bằng tiện ích mới.

Đây là ý của chúng ta khi nói rằng widget là bất biến. Chúng không thay đổi — chúng được thay thế.

Bây giờ chúng ta đã biết nơi đặt trạng thái của giỏ hàng, hãy xem cách truy cập vào nó.

Truy cập trạng thái

Khi người dùng nhấp vào một trong các mặt hàng trong danh mục, mặt hàng đó sẽ được thêm vào giỏ hàng. Nhưng kể từ khi giỏ hàng nằm trên MyListItem, chúng ta làm điều đó như thế nào?

Một tùy chọn đơn giản là cung cấp một lệnh gọi lại mà MyListItem có thể gọi khi nó được nhấp vào. Các hàm của Dart là các đối tượng hạng nhất, vì vậy bạn có thể chuyển chúng theo bất kỳ cách nào bạn muốn. Vì vậy, bên trong MyCatalog, bạn có thể xác định những điều sau:

Điều này hoạt động tốt, nhưng đối với một trạng thái ứng dụng mà bạn cần sửa đổi từ nhiều nơi khác nhau, bạn sẽ phải chuyển qua nhiều lần gọi lại — điều này sẽ cũ đi khá nhanh.

May mắn thay, Flutter có các cơ chế để các widget cung cấp dữ liệu và dịch vụ cho con cháu của chúng (nói cách khác, không chỉ con cái của chúng mà bất kỳ widget nào bên dưới chúng). Như bạn mong đợi từ Flutter, nơi mọi thứ đều là Widget, các cơ chế này chỉ là những loại widget đặc biệt — InheritedWidget, InheritedNotifier, InheritedModel, v.v. Chúng ta sẽ không đề cập đến những điều đó ở đây, vì chúng hơi thấp so với những gì chúng ta đang cố gắng thực hiện.

Thay vào đó, chúng ta sẽ sử dụng một gói hoạt động với các widget cấp thấp nhưng dễ sử dụng. Nó được gọi là nhà cung cấp.

Trước khi làm việc với nhà cung cấp, đừng quên thêm phần phụ thuộc vào nhà cung cấp đó vào pubspec.yaml của bạn.

Bây giờ bạn có import ‘package:provider/provider.dart’; và bắt đầu xây dựng.

Với provider, bạn không cần phải lo lắng về các cuộc gọi lại hoặc InheritedWidgets. Nhưng bạn cần hiểu 3 khái niệm:

• ChangeNotifier
• ChangeNotifierProvider
• Consumer

ChangeNotifier

ChangeNotifier là một lớp đơn giản có trong Flutter SDK cung cấp thông báo thay đổi cho người nghe của nó. Nói cách khác, nếu thứ gì đó là ChangeNotifier, bạn có thể đăng ký các thay đổi của nó. (Đây là một dạng có thể quan sát được, dành cho những người quen thuộc với thuật ngữ này.)

Trong provider, ChangeNotifier là một cách để đóng gói trạng thái ứng dụng của bạn. Đối với các ứng dụng rất đơn giản, bạn có thể sử dụng với một ChangeNotifier duy nhất. Trong những cái phức tạp, bạn sẽ có một số mô hình và do đó là một số ChangeNotifier. (Bạn hoàn toàn không cần sử dụng ChangeNotifier với provider, nhưng đó là một lớp dễ làm việc.)

Trong ví dụ về ứng dụng mua sắm của chúng ta, chúng ta muốn quản lý trạng thái của giỏ hàng trong ChangeNotifier. Chúng ta tạo một lớp mới để mở rộng nó, giống như vậy

Code duy nhất dành riêng cho ChangeNotifier là lệnh gọi tới notificationListists (). Gọi phương thức này bất cứ khi nào mô hình thay đổi theo cách có thể thay đổi giao diện người dùng của ứng dụng của bạn. Mọi thứ khác trong CartModel là chính mô hình và logic của nó.

ChangeNotifierProvider

ChangeNotifierProvider là widget cung cấp một phiên bản của ChangeNotifier cho con cháu của nó. Nó đến từ provider package.

Chúng ta đã biết nơi đặt ChangeNotifierProvider: phía trên các widget cần truy cập nó. Trong trường hợp của CartModel, điều đó có nghĩa là ở đâu đó trên cả MyCart và MyCatalog.

Bạn không muốn đặt ChangeNotifierProvider cao hơn mức cần thiết (vì bạn không muốn làm giảm hiệu suất). Nhưng trong trường hợp của chúng ta, tiện ích duy nhất nằm trên cả MyCart và MyCatalog là MyApp.

Consumer

Bây giờ CartModel đã được cung cấp cho các widget trong ứng dụng của chúng ta thông qua khai báo ChangeNotifierProvider ở trên cùng, chúng ta có thể bắt đầu sử dụng nó.

Điều này được thực hiện thông qua tiện ích Consumer widget.

Chúng ta phải chỉ định loại mô hình mà chúng ta muốn truy cập. Trong trường hợp này, chúng ta muốn CartModel, vì vậy chúng ta viết Consumer <CartModel>. Nếu bạn không chỉ định chung chung (<CartModel>), provider sẽ không thể giúp bạn. Provider dựa trên các loại và nếu không có loại, nó không biết bạn muốn gì.

Đối số bắt buộc duy nhất của Consumer Widget là trình tạo. Builder là một hàm được gọi bất cứ khi nào ChangeNotifier thay đổi. (Nói cách khác, khi bạn gọi thông báo () trong mô hình của mình, tất cả các phương thức trình tạo của tất cả Consumer Widget tương ứng sẽ được gọi.)

Trình tạo được gọi với ba đối số. Điều đầu tiên là ngữ cảnh, mà bạn cũng nhận được trong mọi phương pháp xây dựng.

Đối số thứ hai của hàm trình tạo là phiên bản của ChangeNotifier. Đó là những gì chúng ta đã yêu cầu ngay từ đầu. Bạn có thể sử dụng dữ liệu trong mô hình để xác định giao diện người dùng sẽ trông như thế nào tại bất kỳ điểm nhất định nào.

Đối số thứ ba là con, ở đó để tối ưu hóa. Nếu bạn có một cây con tiện ích con lớn trong Consumer Widget không thay đổi khi mô hình thay đổi, bạn có thể tạo nó một lần và lấy nó thông qua trình tạo.

1. Multiprogramming

Trong một hệ thống máy tính hiện đại, thường có một số tiến trình ứng dụng đồng thời muốn thực thi. Giờ đây, hệ điều hành có trách nhiệm quản lý tất cả các quy trình một cách hiệu quả và hiệu quả.

Một trong những khía cạnh quan trọng nhất của hệ điều hành là đa chương trình.

Trong một hệ thống máy tính, có nhiều quá trình đang chờ được thực thi, tức là chúng đang đợi khi CPU sẽ được cấp phát cho chúng và chúng bắt đầu thực thi. Các quy trình này còn được gọi là công việc. Bây giờ bộ nhớ chính quá nhỏ để chứa tất cả các quy trình hoặc công việc này vào đó. Do đó, các quy trình này ban đầu được lưu giữ trong một khu vực được gọi là nhóm công việc. Nhóm công việc này bao gồm tất cả các quy trình đang chờ cấp phát bộ nhớ chính và CPU.

CPU chọn một công việc trong số tất cả các công việc đang chờ này, đưa nó từ nhóm công việc đến bộ nhớ chính và bắt đầu thực thi nó. Bộ xử lý thực hiện một công việc cho đến khi nó bị gián đoạn bởi một số yếu tố bên ngoài hoặc nó thực hiện một tác vụ I / O.

Hệ thống không đa chương trình đang hoạt động:

• Trong một hệ thống không đa lập trình, Ngay sau khi một công việc rời khỏi CPU và thực hiện một số tác vụ khác (ví dụ I / O), CPU sẽ trở nên nhàn rỗi. CPU tiếp tục chờ và đợi cho đến khi công việc này (đã được thực thi trước đó) quay trở lại và tiếp tục thực hiện với CPU. Vì vậy, CPU vẫn miễn phí trong tất cả thời gian này.
• Bây giờ nó có một nhược điểm là CPU không hoạt động trong một thời gian rất dài. Ngoài ra, các công việc khác đang chờ thực hiện có thể không có cơ hội thực hiện vì CPU vẫn được phân bổ cho công việc trước đó. Điều này đặt ra một vấn đề rất nghiêm trọng là mặc dù các công việc khác đã sẵn sàng thực thi, CPU không được cấp phát cho chúng vì CPU được phân bổ cho một công việc thậm chí không sử dụng nó (vì nó đang bận trong các tác vụ I / O).
• Không thể xảy ra trường hợp một công việc sử dụng CPU trong 1 giờ trong khi những công việc khác đã chờ đợi trong hàng đợi trong 5 giờ. Để tránh những tình huống như thế này và sử dụng CPU hiệu quả, người ta đã đưa ra khái niệm đa lập trình.

Nhiều hệ thống được chương trình đang hoạt động

• Trong một hệ thống đa lập trình, ngay sau khi một công việc thực hiện một tác vụ I / O, hệ điều hành sẽ ngắt công việc đó, chọn một công việc khác từ nhóm công việc (hàng đợi), cung cấp cho CPU công việc mới này và bắt đầu thực thi nó. Công việc trước đó tiếp tục thực hiện hoạt động I / O của nó trong khi công việc mới này thực hiện các tác vụ ràng buộc CPU. Bây giờ giả sử công việc thứ hai cũng áp dụng cho một tác vụ I / O, CPU chọn công việc thứ ba và bắt đầu thực thi nó. Ngay sau khi một công việc hoàn thành hoạt động I / O của nó và quay trở lại với các tác vụ của CPU, CPU sẽ được cấp phát cho nó.
• Bằng cách này, không có thời gian CPU bị lãng phí bởi hệ thống chờ đợi tác vụ I / O được hoàn thành. Do đó, mục tiêu cuối cùng của lập trình đa là giữ cho CPU luôn bận rộn miễn là có các tiến trình sẵn sàng thực thi. Bằng cách này, nhiều chương trình có thể được thực thi trên một bộ xử lý bằng cách thực thi một phần của chương trình tại một thời điểm, một phần của chương trình khác sau phần này, sau đó là một phần của chương trình khác, v.v., do đó thực thi nhiều chương trình. Do đó, CPU không bao giờ ngừng hoạt động.

Trong hình dưới đây, chương trình A chạy một thời gian rồi chuyển sang trạng thái chờ. Trong thời gian trung bình, chương trình B bắt đầu thực hiện. Vì vậy, CPU không lãng phí tài nguyên của nó và tạo cơ hội cho chương trình B chạy.

2. Multiprocessing

Trong hệ thống đơn bộ xử lý, chỉ có một quá trình thực thi tại một thời điểm.

Đa xử lý là việc sử dụng hai hoặc nhiều CPU (bộ xử lý) trong một hệ thống máy tính. Thuật ngữ này cũng đề cập đến khả năng của một hệ thống hỗ trợ nhiều hơn một bộ xử lý trong một hệ thống máy tính duy nhất. Bây giờ vì có nhiều bộ xử lý có sẵn, nhiều quá trình có thể được thực hiện cùng một lúc. Các bộ xử lý đa này chia sẻ bus máy tính, đôi khi cả đồng hồ, bộ nhớ và các thiết bị ngoại vi.

Nhiều hệ thống xử lý đang hoạt động:

• Với sự trợ giúp của đa xử lý, nhiều quá trình có thể được thực hiện đồng thời. Giả sử các quá trình P1, P2, P3 và P4 đang chờ thực thi. Bây giờ trong một hệ thống xử lý duy nhất, trước hết một quá trình sẽ thực thi, sau đó là quá trình kia, sau đó là quá trình khác, v.v.
• Nhưng với đa xử lý, mỗi quá trình có thể được gán cho một bộ xử lý khác nhau để thực hiện. Nếu nó là bộ xử lý lõi kép (2 bộ xử lý), hai quá trình có thể được thực thi đồng thời và do đó sẽ nhanh hơn hai lần, tương tự bộ vi xử lý lõi tứ sẽ nhanh hơn bốn lần so với bộ xử lý đơn.

Tại sao sử dụng đa xử lý?

• Ưu điểm chính của hệ thống đa xử lý là hoàn thành nhiều công việc hơn trong một khoảng thời gian ngắn hơn. Các loại hệ thống này được sử dụng khi yêu cầu tốc độ rất cao để xử lý một khối lượng lớn dữ liệu. Hệ thống đa xử lý có thể tiết kiệm tiền so với hệ thống xử lý đơn vì các bộ xử lý có thể dùng chung thiết bị ngoại vi và nguồn cung cấp năng lượng.
• Nó cũng cung cấp độ tin cậy cao hơn theo nghĩa là nếu một bộ xử lý bị lỗi, công việc sẽ không dừng lại mà chỉ chậm lại. ví dụ. nếu chúng ta có 10 bộ vi xử lý và 1 bộ xử lý bị lỗi, thì công việc sẽ không dừng lại, đúng hơn là 9 bộ vi xử lý còn lại có thể chia sẻ công việc của bộ xử lý thứ 10. Do đó, toàn bộ hệ thống chỉ chạy chậm hơn 10 phần trăm, chứ không phải là thất bại hoàn toàn.

Đa xử lý đề cập đến phần cứng (tức là các đơn vị CPU) chứ không phải phần mềm (tức là các quy trình đang chạy). Nếu phần cứng bên dưới cung cấp nhiều hơn một bộ xử lý thì đó là quá trình đa xử lý. Đó là khả năng của hệ thống tận dụng sức mạnh tính toán của nhiều bộ xử lý.

Sự khác biệt giữa đa chương trình và da xử lý

• Một hệ thống có thể được lập trình đa bằng cách có nhiều chương trình chạy cùng lúc và đa xử lý bằng cách có nhiều hơn một bộ xử lý vật lý. Sự khác biệt giữa đa xử lý và đa lập trình là Đa xử lý về cơ bản là thực hiện nhiều quy trình cùng lúc trên nhiều bộ xử lý, trong khi đa lập trình là lưu giữ một số chương trình trong bộ nhớ chính và thực thi chúng đồng thời chỉ bằng một CPU duy nhất.
• Đa xử lý xảy ra bằng cách xử lý song song trong khi Đa lập trình xảy ra bằng cách chuyển từ quá trình này sang quá trình khác (hiện tượng được gọi là chuyển mạch ngữ cảnh).

3. Multitasking

Như tên gọi của chính nó, đa tác vụ đề cập đến việc thực thi nhiều tác vụ (chẳng hạn như quy trình, chương trình, luồng, v.v.) tại một thời điểm. Trong các hệ điều hành hiện đại, chúng ta có thể phát nhạc MP3, chỉnh sửa tài liệu trong Microsoft Word và lướt Google Chrome đồng thời, điều này được thực hiện nhờ đa tác vụ.

Đa nhiệm là một phần mở rộng hợp lý của đa lập trình. Cách chính mà đa nhiệm khác với đa lập trình là lập trình đa hoạt động chỉ dựa trên khái niệm chuyển đổi ngữ cảnh trong khi đa nhiệm dựa trên chia sẻ thời gian cùng với khái niệm chuyển đổi ngữ cảnh.

Hệ thống đa nhiệm đang hoạt động:

• Trong một hệ thống chia sẻ thời gian, mỗi quá trình được ấn định một số lượng thời gian cụ thể để một quá trình thực thi. Giả sử có 4 quy trình P1, P2, P3 và P4 sẵn sàng thực thi. Vì vậy, mỗi người trong số họ được gán một số lượng tử thời gian mà chúng sẽ thực thi, ví dụ lượng tử thời gian 5 nano giây (5 ns). Khi một quá trình bắt đầu thực hiện (ví dụ P2), nó sẽ thực thi trong lượng tử thời gian đó (5 ns). Sau 5 ns, CPU bắt đầu thực hiện quá trình khác (ví dụ P3) trong lượng tử thời gian được chỉ định.
• Do đó, CPU làm cho các tiến trình chia sẻ các lát thời gian giữa chúng và thực thi tương ứng. Ngay sau khi lượng tử thời gian của một quá trình hết hạn, một quá trình khác sẽ bắt đầu thực hiện.
• Ở đây về cơ bản cũng có một chuyển đổi ngữ cảnh đang xảy ra nhưng nó xảy ra quá nhanh đến mức người dùng có thể tương tác với từng chương trình riêng biệt trong khi nó đang chạy. Bằng cách này, người dùng có ảo tưởng rằng nhiều quy trình / tác vụ đang thực hiện đồng thời. Nhưng trên thực tế, chỉ có một tiến trình / tác vụ được thực thi tại một thời điểm cụ thể. Trong đa nhiệm, chia sẻ thời gian được thể hiện tốt nhất bởi vì mỗi quá trình đang chạy chỉ chiếm một lượng tử thời gian hợp lý của CPU.

Nói một cách khái quát hơn, đa nhiệm là việc có nhiều chương trình, tiến trình, tác vụ, luồng chạy cùng một lúc. Thuật ngữ này được sử dụng trong các hệ điều hành hiện đại khi nhiều tác vụ chia sẻ một tài nguyên xử lý chung (ví dụ: CPU và Bộ nhớ).

• Như được mô tả trong hình trên, Tại bất kỳ thời điểm nào CPU chỉ thực hiện một tác vụ trong khi các tác vụ khác đang chờ đến lượt. Ảo tưởng về sự song song đạt được khi CPU được phân công lại cho một nhiệm vụ khác. tức là tất cả ba nhiệm vụ A, B và C dường như xảy ra đồng thời vì chia sẻ thời gian.
• Vì vậy, để đa nhiệm diễn ra, trước tiên phải có đa chương trình, tức là sự hiện diện của nhiều chương trình sẵn sàng để thực thi. Và thứ hai là khái niệm chia sẻ thời gian.

4. Multithreading

Một luồng là một đơn vị cơ bản của việc sử dụng CPU. Đa luồng là một mô hình thực thi cho phép một quá trình có nhiều đoạn mã (tức là các luồng) chạy đồng thời trong “ngữ cảnh” của quá trình đó.

Ví dụ. Trình phát phương tiện VLC, trong đó một luồng được sử dụng để mở trình phát phương tiện VLC, một luồng để phát một bài hát cụ thể và một luồng khác để thêm các bài hát mới vào danh sách phát.

Đa luồng là khả năng của một quá trình quản lý việc sử dụng nó bởi nhiều người dùng tại một thời điểm và quản lý nhiều yêu cầu của cùng một người dùng mà không cần phải có nhiều bản sao của chương trình.

Hệ thống đa luồng đang hoạt động:

Trường hợp 1:

• Giả sử có một máy chủ web xử lý các yêu cầu của khách hàng. Bây giờ nếu nó thực thi như một quy trình đơn luồng, thì nó sẽ không thể xử lý nhiều yêu cầu cùng một lúc. Đầu tiên, một máy khách sẽ đưa ra yêu cầu của mình và hoàn thành việc thực thi và chỉ sau đó, máy chủ mới có thể xử lý yêu cầu của một máy khách khác. Đây là một công việc thực sự tốn kém, mất thời gian và mệt mỏi. Để tránh điều này, có thể sử dụng đa luồng.
• Bây giờ, bất cứ khi nào có yêu cầu của khách hàng mới, máy chủ web chỉ cần tạo một luồng mới để xử lý yêu cầu này và tiếp tục thực thi để nghe thêm các yêu cầu của khách hàng. Vì vậy máy chủ web có nhiệm vụ lắng nghe các yêu cầu mới của khách hàng và tạo các luồng cho từng yêu cầu riêng lẻ. Mỗi luồng mới được tạo xử lý một yêu cầu của khách hàng, do đó giảm bớt gánh nặng cho máy chủ web.

Trường hợp 2:

• Chúng ta có thể coi các luồng là các quy trình con chia sẻ tài nguyên quy trình mẹ nhưng thực thi độc lập. Bây giờ hãy lấy trường hợp của GUI. Giả sử chúng tôi đang thực hiện một phép tính trên GUI (mất rất nhiều thời gian để hoàn thành). Bây giờ chúng ta không thể tương tác với phần còn lại của GUI cho đến khi lệnh này kết thúc quá trình thực thi. Để có thể tương tác với phần còn lại của GUI, lệnh tính toán này nên được gán cho một luồng riêng biệt. Vì vậy, tại thời điểm này, 2 luồng sẽ thực thi, tức là một để tính toán và một cho phần còn lại của GUI. Do đó, ở đây trong một quy trình duy nhất, chúng tôi đã sử dụng nhiều luồng cho nhiều chức năng.

Hình ảnh dưới đây mô tả hoàn toàn ví dụ về trình phát VLC:

Ưu điểm của đa luồng

• Lợi ích của Đa luồng bao gồm tăng khả năng phản hồi. Vì có nhiều luồng trong một chương trình, vì vậy nếu một luồng mất quá nhiều thời gian để thực thi hoặc nếu nó bị chặn, phần còn lại của luồng sẽ tiếp tục thực thi mà không gặp bất kỳ sự cố nào. Do đó, toàn bộ chương trình vẫn đáp ứng cho người dùng bằng các luồng còn lại.
• Một ưu điểm khác của đa luồng là nó ít tốn kém hơn. Tạo các quy trình hoàn toàn mới và phân bổ tài nguyên là một công việc tốn nhiều thời gian, nhưng vì các luồng chia sẻ tài nguyên của quy trình mẹ nên việc tạo các luồng và chuyển đổi giữa chúng tương đối dễ dàng. Do đó đa luồng là nhu cầu của các Hệ điều hành hiện đại.

Cảm ơn mọi người đã theo dõi.

Author: DuongVT19