Permasalahan critical section adalah masalah yang terjadi dalam pemrograman paralel ketika beberapa proses atau thread bersaing untuk mengakses sumber daya bersama. Sumber daya bersama ini dapat berupa variabel global, file, atau perangkat keras. Sehingga hal ini menyebabkan suatu kondisi yang dianggap sebagai kerentanan “Race Condition” dalam kamus IT Security.
Critical section adalah bagian dari kode yang mengakses atau memodifikasi sumber daya bersama. Ketika sebuah proses atau thread berada di dalam critical section, proses atau thread lain tidak boleh mengakses sumber daya tersebut. Jika tidak, dapat terjadi race condition, di mana hasil akhir dari program bergantung pada urutan eksekusi proses atau thread yang tidak dapat diprediksi. Hal ini dapat mengakibatkan hasil yang tidak konsisten atau tidak diinginkan.
Misalnya, pertimbangkan sebuah program yang memiliki dua proses, P1 dan P2. Masing-masing proses memiliki variabel global bernama jumlah. Proses P1 menambah nilai jumlah sebesar 1, sedangkan proses P2 mengurangi nilai jumlah sebesar 1. Jika kedua proses ini mengakses variabel jumlah secara bersamaan, dapat terjadi RACE CONDITION. Misalnya, jika proses P1 sedang menambah nilai jumlah, sedangkan proses P2 sedang mengurangi nilai jumlah, maka nilai jumlah akan menjadi tidak konsisten.
Ada 3 syarat yang wajib dipenuhi untuk mengatasi permasalahan Critical Section (Khususnya Race Condition):
1. Mutual Expression (Mutex)
Hanya satu proses atau thread yang dapat mengakses sumber daya bersama pada satu waktu.
2. Progress
Jika ada proses atau thread yang ingin mengakses sumber daya bersama, proses atau thread tersebut harus dapat mengaksesnya pada akhirnya.
3. Bounded waiting
Suatu proses harus menunggu beberapa lama untuk mendapatkan akses ke bagian kritis jika proses lain memiliki hak untuk mengaksesnya. Ini dilakukan untuk memastikan bahwa proses tersebut dapat mengakses bagian kritis. Tidak ada asumsi tentang kecepatan eksekusi proses di bagian ini.
Lalu solusi algoritma yang dapat dipakai:
1. Solusi Peterson
Solusi Peterson adalah algoritma critical section yang pertama kali diusulkan oleh Peterson pada tahun 1981. Algoritma ini menggunakan tiga variabel global untuk memastikan bahwa hanya satu proses atau thread yang dapat mengakses sumber daya bersama pada satu waktu.
2. Penggunaan Kunci (Lock)
Kunci adalah mekanisme yang digunakan untuk memastikan bahwa hanya satu proses atau thread yang dapat mengakses sumber daya bersama pada satu waktu. Kunci dapat diimplementasikan dengan menggunakan variabel global atau dengan menggunakan struktur data khusus, seperti mutex atau semaphore. Untuk menggunakan kunci, proses atau thread harus terlebih dahulu memperoleh kunci. Proses atau thread yang telah memperoleh kunci dapat mengakses sumber daya bersama. Proses atau thread yang ingin memperoleh kunci harus menunggu hingga kunci tersedia. Setelah proses atau thread selesai mengakses sumber daya bersama, proses atau thread tersebut harus melepaskan kunci.
3. Sinkronisasi Perangkat Keras
Sinkronisasi perangkat keras adalah mekanisme yang digunakan untuk mengontrol akses ke sumber daya bersama menggunakan perangkat keras. Mekanisme ini biasanya lebih efisien daripada mekanisme sinkronisasi perangkat lunak, seperti mutex atau semaphore.
4. Solusi TestAndSet
Solusi TestAndSet adalah algoritma critical section yang menggunakan operasi TestAndSet untuk memastikan bahwa hanya satu proses atau thread yang dapat mengakses sumber daya bersama pada satu waktu. Operasi TestAndSet adalah operasi atomik yang memeriksa nilai suatu variabel dan mengubah nilai variabel tersebut jika nilai variabel tersebut belum berubah.
Baca Juga:
1. HTTP Request Smuggling, Kerentanan Unik Dari HTTP/1.1
2. Saya Bertanya Kepada AI Mengenai Pentesting, Begini Jawabannya!Race Condition
Lalu kita bergeser ke real case sedikit… pada dasarnya hampir semua programmer yang berhubungan dengan data transaksi seringkali kewalahan dengan “Race Condition” dari hasil security testing atau uji keamanan yang ada pada setiap instansi perusahaan. Pada tahun 2020/2021 Tokopedia saat itu masih banyak memiliki kerentanan, salah satunya “Race Condition”. Makanya saat itu teman-teman sejawat sesama penggiat IT Security seringkali memanfaatkan fitur Race Condition pada barang diskon ataupun kupon diskon, sehingga mereka bisa memakai sesuka hati dan berulang kali.
Dari narasi di atas ada beberapa metode yang dapat di implementasi untuk mengatasi salah satu problem Cricitical Section, yaitu race Condition. Metode-metode yang sering dipakai dalam keseharian para programmer untuk mengatasi hal tersebut dengan menggunakan “penggunaan kunci (lock)” ataupun “Solusi TestAndSet” antara lain, Mutual Expression (Mutex atau kadang disebut juga sebagai atomic Operation), Optimistic Concurrency Control, dan Pessimistic Concurrency Control.
A. Mutual Expression (Mutex atau kadang disebut juga sebagai atomic Operation)
Mutual exclusion adalah mekanisme yang digunakan untuk memastikan bahwa hanya satu proses atau thread yang dapat mengakses sumber daya bersama pada satu waktu. Mekanisme ini digunakan untuk menghindari race condition, di mana hasil akhir dari program bergantung pada urutan eksekusi proses atau thread yang tidak dapat diprediksi. Mutex adalah salah satu mekanisme mutual exclusion yang paling umum digunakan. Mutex adalah variabel yang dapat memiliki nilai 0 atau 1. Nilai 0 berarti mutex tidak sedang digunakan, sedangkan nilai 1 berarti mutex sedang digunakan.
Untuk menggunakan mutex, proses atau thread harus terlebih dahulu memperoleh mutex. Proses atau thread yang telah memperoleh mutex dapat mengakses sumber daya bersama. Proses atau thread yang ingin memperoleh mutex harus menunggu hingga mutex tersedia. Setelah proses atau thread selesai mengakses sumber daya bersama, proses atau thread tersebut harus melepaskan mutex.
B. Optimistic Concurrency Control
Optimistic concurrency control adalah mekanisme concurrency control yang mengasumsikan bahwa konflik jarang terjadi. Dalam mekanisme ini, beberapa proses atau thread dapat mengakses sumber daya bersama secara bersamaan. Namun, jika terjadi konflik, konflik tersebut akan dideteksi dan diselesaikan setelah proses atau thread selesai mengakses sumber daya bersama. Optimistic concurrency control biasanya lebih efisien daripada pessimistic concurrency control, tetapi mekanisme ini dapat menyebabkan data yang tidak konsisten jika terjadi konflik.
C. Pessimistic Concurrency Control
Pessimistic concurrency control adalah mekanisme concurrency control yang mengasumsikan bahwa konflik selalu terjadi. Dalam mekanisme ini, proses atau thread harus memperoleh kunci sebelum dapat mengakses sumber daya bersama. Kunci adalah mekanisme yang memastikan bahwa hanya satu proses atau thread yang dapat mengakses sumber daya bersama pada satu waktu. Pessimistic concurrency control biasanya lebih aman daripada optimistic concurrency control, tetapi mekanisme ini dapat menyebabkan kinerja yang lebih rendah karena proses atau thread harus menunggu hingga kunci tersedia.
Nah dari case yang paling sering ditemukan biasanya adalah “Pessimistic Concurency Control”, namun itu tetap tergantung case dan bagaimana arsitektur hinggal flow program berjalan. Lalu saya juga melihat beberapa pertanyaan terkait dedalock, maka pembahasan di bawah akan menjelaskan apa itu “Deadlock” dan mengapa solusi yang saya jabarkan di atas dapat mengatasi deadlock.
