Add intro blog for STL Concurrency primitives GSoC 2025 project (#295)

Author: pmozil

.github/actions/spelling/allow/terms.txt

@@ -33,6 +33,7 @@ gitlab
 gridlay
 gsoc
 gpu
+jthread
 llm
 llvm
 pushforward

_data/contributors.yml

@@ -275,6 +275,30 @@
        potentially establishing a new standard for high-performance genomic data analysis.
       proposal: /assets/docs/Aditya_Pandey_GSoC2025.pdf
       mentors: Martin Vassilev, Jonas Rembser, Fons Rademakers, Vassil Vassilev
+
+- name: Petro Mozil
+  photo: PetroMozil.jpeg
+  info: "Google Summer of Code 2025 Contributor"
+  email: [email protected]
+  education: "Bachelor of Computer Science, Ukrainian Catholic University, Ukraine"
+  github: "https://github.com/pmozil"
+  active: 1
+  linkedin: "https://www.linkedin.com/in/petro-mozil-a94583170/"
+  projects:
+    - title: "Enabling support for STL concurrency primitives in CLAD"
+      status: Ongoing
+      description: |
+        Clad recursively iterates over the syntax tree to check whether a given 
+        statement should be differentiated. Each function that is called from 
+        inside of a differentiated function should be differentiated as well, 
+        and so should any object method. The main issue for clad is that std::thread is an object, 
+        and thus as a type that should be differentiated However, std::thread shouldn’t 
+        be differentiated, the function inside of it should. 
+        Some of STL’s concurrency primitives face the same problem - 
+        the methods in them should not be differentiated, 
+        and only the location of where they were called should be preserved.
+      proposal: /assets/docs/petro_mozil_promosal_GSoC_2025.pdf
+      mentors: Martin Vassilev, David Lange
 
 - name: Salvador de la Torre Gonzalez
   info: "Google Summer of Code 2025 Contributor"

_pages/team/petro-mozil.md

@@ -0,0 +1,10 @@
+---
+title: "Compiler Research - Team - Petro Mozil"
+layout: gridlay
+excerpt: "Compiler Research: Team members"
+sitemap: false
+permalink: /team/PetroMozil
+email: [email protected]
+---
+
+{% include team-profile.html %}

_posts/2025-05-18-Supporting-STL-concurrency-primitives-in-clad.md

@@ -0,0 +1,50 @@
+---
+title: "Supporting STL Concurrency Primitives in CLAD"
+layout: post
+excerpt: "Support for STL concurrency features in CLAD is a useful feature for applications utilizing cpu threads. Many applications of autodifferentiation benefit from parallel or concurrent processing, and support for some STL concurrency primitives such as threads and basic synchronization primitives may considerably simplify the user's design."
+sitemap: false
+author: Petro Mozil
+permalink: blogs/gsoc25_/
+banner_image: /images/blog/gsoc-banner.png
+date: 2025-05-18
+tags: gsoc llvm clang auto-differentiation
+---
+
+## About me
+
+I am Petro Mozil, a student participating in the Google Summer of Code program in 2025.
+I will work on adding support of STL concurrency primitives to CLAD.
+
+## Problem description
+
+`Clad` is a plugin for automatic differentiation for the `clang` compiler.
+Automatic differentiation is a term for multiple techniques of deriving a mathematical function analytically. Some of the ways of doing this include simply calculating the derivative numerically or by deriving a function by a set of rules, symbolically.
+
+`Clad` provides an interface that returns an object that contained the derivative of a given function. There might be problems with some functions, if they are to be derived. For example, one would not derive `printf`,  and neither would they derive `std::tread` - those are exceptions, and should be handled differently from mathematical  functions.
+
+The main goals of this project are to implement support for automatically derive functions that contain `std::thread` so that the user wouldn't have to separate the multi-processing logic from the mathematical functions - such a feature would be a great time-saver for production of multi-processing code.
+
+## Objectives
+
+The objectives for this project include adding support for multiple objects in STL, such as `std::thread`, `std::atomic`, `std::mutex`.
+
+The first, and, likely, most important part of the project is to add support for `std::thread` - this will include deriving not the `std::thread` constructor, but deriving the function supplied for the thread.
+
+Support for mutexes is a bit more straightforward - though `clad` creates a second object to represent the derived value, it shouldn't do so for a mutex. It is a matter of having a custom derivative for `std::mutex`.
+
+Atomics will likely involve more effort - they would require custom derivatives for `compare_exchange` functions as well as their methods.
+
+If time allows, I would also like to add support for `std::condition_variable`, `std::lock_guard`, `std::unique_lock` and `std::jthread`, and most of those would also only involve a custom derivative.
+
+
+## Conclusion
+
+A a result of this project, support for the concurrency primitives is expected. Clad should seamlessly derive functions with concurrency primitives in them.
+Though this project does not focus on features immediately required from `clad`, it should result in making easier the lives of those, who use clad for high-perf computing.
+
+## Related links
+
+- [LLVM Repository](https://github.com/llvm/llvm-project)
+- [CLAD repository](https://github.com/vgvassilev/clad)
+- [Project description](https://hepsoftwarefoundation.org/gsoc/2025/proposal_Clad-STLConcurrency.html)
+- [My github](https://github.com/pmozil)