DEV Community: Somenath Mukhopadhyay

Class level locking in C++ - serializing multiple threads...

Somenath Mukhopadhyay — Sat, 23 May 2026 08:53:59 +0000

When I studied Android AsyncTask, especially when serialexecutor was the norm, I found how Google engineers have designed to serialize execution of multiple threads. My original code simulating similar effects using Java was done more than a decade ago. Here it is.

Read the full article on Som's Tech World

Today I did the same effect, but this time with modern C++.

Here we go.


//============================================================================
// Name        : ClassLevelLockingThreadSerialization.cpp
// Author      : Som
// Version     :
// Copyright   : som-itsolutions
// Description : Hello World in C++, Ansi-style
//============================================================================

#include <iostream>
#include <future>
#include <chrono>
#include <mutex>

class ExampleClass {
private:
    static std::mutex classMutex;

public:

    static void testMethod(const std::string& threadName) {

        std::lock_guard<std::mutex> lock(classMutex);

        for (int i = 0; i < 10; i++) {

            std::cout
                << "The testMethod for "
                << threadName
                << std::endl;

            std::this_thread::sleep_for(
                std::chrono::seconds(1)
            );
        }
    }
};

std::mutex ExampleClass::classMutex;

int main() {

    auto f1 = std::async(
        std::launch::async,
        ExampleClass::testMethod,
        "Thread 1"
    );

    auto f2 = std::async(
        std::launch::async,
        ExampleClass::testMethod,
        "Thread 2"
    );

    f1.get();
    f2.get();
}

Understanding the Synchronization
The important part of the program is:

std::lock_guard<std::mutex> lock(classMutex);

This line acquires the mutex before entering the critical section. Since the mutex is declared as static, it is shared across all threads and all invocations of the method.

As a result:

only one thread can execute testMethod() at a time
the second thread waits until the first thread releases the mutex
thread execution becomes serialized
This is conceptually similar to Java’s static synchronized methods.

Why Use std::lock_guard?

Modern C++ prefers RAII-based locking instead of manually calling:

mutex.lock();
mutex.unlock();

std::lock_guard automatically releases the mutex when the object goes out of scope, making the code safer and exception-resistant.

Why Use std::async?

Instead of manually creating and managing std::thread objects, std::async provides a higher-level abstraction for asynchronous task execution.

Benefits include:

automatic thread management
future-based synchronization
cleaner code
safer resource handling

Final Thoughts

Modern C++ concurrency has evolved significantly from traditional thread programming. Features such as futures, mutexes, async execution, coroutines, and task systems enable developers to write safer and more scalable concurrent applications.

This small example demonstrates a foundational concept that appears everywhere in modern systems programming:

game engines
rendering systems
simulation frameworks
CAD software
scientific computing systems

Understanding synchronization primitives like mutexes is an important first step toward mastering advanced concurrent architectures in modern C++.

Class Level Locking in Java - inspired by Android's AsyncTask implementation - serializing multiple threads...

Somenath Mukhopadhyay — Thu, 14 May 2026 03:33:08 +0000

After many months, I have opened my Java workspace and saw my implementation of Class Level locking, which was inspired by Android's AsyncTask.

Here is the source code...

package com.somitsolutions.java.training.classlevellockingwithstaticnestedclass;


public class ExampleClass {

    public ExampleClass(){  
    }

    public static InnerNestedClass objInnerNestedClass = new InnerNestedClass();

    static class InnerNestedClass{
        public synchronized void testMethod(){
            try {
                for (int i = 0; i<10; i++){
                    System.out.println ("The testMethod for "  + Thread.currentThread().getName()  + " Object");
                    Thread.sleep(2000);
                }

            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }

        }
    }
}

package com.somitsolutions.java.training.classlevellockingwithstaticnestedclass;

public class R implements Runnable{
    final ExampleClass exampleClassObject = new ExampleClass();
    //final ExampleClass exampleClassObject2 = new ExampleClass();
    public void run(){
        exampleClassObject.objInnerNestedClass.testMethod(); 
    }
}

package com.somitsolutions.java.training.classlevellockingwithstaticnestedclass;

public class Main {

    public static void main(String[] args) {
        // TODO Auto-generated method stub

        R r1 = new R();
        R r2 = new R();
        Thread t1 = new Thread(r1);
        Thread t2 = new Thread(r2);
        t1.setName("Thread 1");
        t2.setName("Thread 2");
        t1.start();
        t2.start();
    }
}

1. What Exactly Is Happening Here?

We have:

public static InnerNestedClass objInnerNestedClass = new InnerNestedClass();

This line is the key.

Because the object is declared static, there is only one instance of InnerNestedClass for the entire JVM class ExampleClass.

No matter how many ExampleClass objects you create:

new ExampleClass();
new ExampleClass();
new ExampleClass();

they all share:

ExampleClass.objInnerNestedClass

There is exactly ONE monitor lock associated with that object.

2. Understanding the Synchronization

Inside the nested class:

public synchronized void testMethod()

This means:

synchronized(this)

So the lock is acquired on:

objInnerNestedClass

Since there is only ONE static instance:

public static InnerNestedClass objInnerNestedClass

all threads compete for the SAME monitor lock.

3. Flow of Execution

Step-by-step

You create:

R r1 = new R();
R r2 = new R();

Each R object creates its own:

final ExampleClass exampleClassObject = new ExampleClass();

So now you have:

Two different ExampleClass objects
BUT both point to the SAME static object

Conceptually:

ExampleClass Object A
        |
        ---> static objInnerNestedClass ----> [ONE OBJECT]

ExampleClass Object B
        |
        ---> static objInnerNestedClass ----> [SAME OBJECT]

4. What Happens When Threads Run?

Thread 1:

exampleClassObject.objInnerNestedClass.testMethod();

Thread 2:

exampleClassObject.objInnerNestedClass.testMethod();

Both are calling:

testMethod()

on the SAME shared object.

Since the method is synchronized:

public synchronized void testMethod()

only ONE thread can enter at a time.

5. Runtime Behavior

Suppose:

Thread 1 enters first
Thread 2 tries to enter

Then:

Thread 1 acquires monitor lock
Thread 2 BLOCKS

Thread 2 waits until:

Thread 1 exits testMethod()

Only then:

Thread 2 acquires lock

So output becomes SERIALIZED:

Thread 1 messages...
Thread 1 messages...
Thread 1 messages...

THEN

Thread 2 messages...
Thread 2 messages...

instead of interleaving.

6. Why This Is Called "Class-Level Locking"

Strictly speaking, true class-level locking is:

synchronized(ExampleClass.class)

public static synchronized void method()

which locks on the Class object itself.

But my example achieves a VERY SIMILAR EFFECT using:

static shared object + synchronized instance method

So effectively:

One shared lock for entire class

Hence, behaviorally, it becomes "class-wide serialization."

7. Why Static Matters

Without static:

public InnerNestedClass objInnerNestedClass

each ExampleClass object would get its OWN nested object.

Then:

Thread 1 -> Lock A
Thread 2 -> Lock B

No contention.

Both threads would run simultaneously.

So static is the entire reason serialization occurs.

8. Relationship to Android AsyncTask

In old Android implementations of Android AsyncTask, Google implemented task serialization using a very similar design.

Internally, AsyncTask had something conceptually similar to:

private static class SerialExecutor implements Executor {
    final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();
    Runnable mActive;

    public synchronized void execute(final Runnable r) {
        ...
    }
}

and:

private static final SerialExecutor sDefaultExecutor
        = new SerialExecutor();

Notice the same pattern:

Shared Static Executor

private static final SerialExecutor sDefaultExecutor

ONE executor object for all AsyncTasks.

Synchronized Method

public synchronized void execute(...)

Only one thread could manipulate scheduling state at a time.

Result

Even if you created:

new MyAsyncTask().execute();
new MyAsyncTask().execute();
new MyAsyncTask().execute();

They were serialized through the SAME shared executor.

So tasks are executed one after another.

This was done to avoid:

race conditions
thread explosion
UI instability
uncontrolled parallelism

especially on low-memory mobile devices.

9. Why Android Did This

Early Android phones had:

very limited RAM
single-core CPUs
weak scheduling capabilities

If developers accidentally launched many background tasks simultaneously:

UI freezes
Battery drain
ANRs
Memory pressure

could happen.

So Android engineers intentionally serialized AsyncTasks.

Later Android versions introduced:

executeOnExecutor(THREAD_POOL_EXECUTOR)

to allow controlled parallelism.

10. Deeper JVM Insight

Every Java object has an associated:

Monitor Lock

When a synchronized instance method is called:

public synchronized void method()

JVM internally does roughly:

monitorenter(this)
...
monitorexit(this)

Since all threads share the SAME static object:

ONE monitor

becomes the synchronization bottleneck.

11. Why Studying Open Source Code Is Important

This is the most important part.

Reading open-source frameworks teaches things that textbooks usually cannot.

For example, from AsyncTask we learn:

real-world concurrency design
serialization strategies
thread scheduling
producer-consumer patterns
executor frameworks
synchronization tradeoffs

Theory vs Reality

A textbook may say:

"synchronized prevents race conditions"

But Android source code shows:

WHY engineers used synchronization
WHERE they used it
WHAT problem they were solving
WHAT tradeoffs they accepted

That is real engineering knowledge.

12. Why Great Engineers Read Source Code

Engineers who study frameworks like:

OpenJDK
Android
Linux kernel
OpenFOAM
FreeCAD

develop:

architectural thinking
systems intuition
debugging maturity
performance awareness
concurrency understanding

far beyond ordinary programming.

13. What You Are Actually Learning Here

My small example contains concepts from:

JVM monitor implementation
object lifetime
static memory model
synchronization semantics
concurrent scheduling
executor design
Android framework architecture

This is exactly why studying framework source code is powerful.

You stop seeing programming as:

"writing syntax"

and begin seeing it as:

"designing systems"

That transition is what separates an average coder from a strong software engineer.

Walking Alone, Building Bharat: Why Intrinsic Motivation Defines the Future of Innovation

Somenath Mukhopadhyay — Sat, 09 May 2026 05:32:00 +0000

There comes a moment in every meaningful journey when a person realizes that leadership is not about applause, followers, or external validation. It is about conviction. It is about walking forward even when nobody accompanies you.

The timeless line from Ekla Chalo Re captures this spirit perfectly:

“If nobody responds to your call, then walk alone.”

This is not merely poetry. It is a philosophy of leadership.

A true leader does not wait for social approval before pursuing truth, innovation, or transformation. The ability to continue despite isolation is perhaps the deepest form of intrinsic motivation. History repeatedly shows that every major civilizational leap began with individuals willing to walk alone against convention.

Today, this mindset is becoming increasingly visible across India — or as many passionately call it, Bharat.

The Rise of a New Bharat

A profound transformation is underway.

For decades, elite education in India was concentrated in a few urban centers. But now, talent is emerging from Tier-2 and Tier-3 cities at an unprecedented scale. Access to knowledge is no longer geographically restricted.

The digital revolution has changed the equation.

Online education, open-source learning, recorded lectures from institutions like Indian Institutes of Technology, National Institutes of Technology, and other premier institutions are democratizing technical education.

The implications are enormous.

If a classroom of twenty students in a top engineering institution can produce two or three future entrepreneurs or researchers, what happens when world-class technical education reaches millions of students across the country through the internet?

The answer is simple:

India’s innovation capacity multiplies exponentially.

From Examination Factories to Knowledge Civilization

For years, one criticism often directed toward India was that the country produced service-sector engineers but lacked large-scale original research and deep technological innovation.

That narrative is beginning to change.

The future belongs to nations capable of producing:

researchers,
deep-tech innovators,
hardware engineers,
graphics programmers,
AI scientists,
simulation experts,
entrepreneurs,
and creators of foundational technology.

India’s growing ecosystem of online technical education, digital libraries, open-source software exposure, and accessible mentorship is slowly laying that foundation.

The next generation is not satisfied with merely consuming technology. They want to build it.

A Small Example of a Bigger Transformation

One of the most striking parts of this story is that the transformation is already visible at the school level.

My son, a Class 9 student, who began learning programming at the age of six. Over time, he explored multiple programming languages, including:

Java
Python
C++

Eventually, his interest moved toward advanced graphics programming using OpenGL.

But the remarkable aspect was not simply learning OpenGL.

Ridit reportedly went further by exposing a custom C++ OpenGL engine to Python using pybind11 — a concept normally encountered in advanced software engineering and systems programming.

This is significant because it reflects something deeper:

Young learners are no longer limiting themselves to textbook knowledge. They are beginning to understand interoperability, engine architecture, bindings, and real-world software ecosystems.

This is precisely how technological civilizations evolve.

The Internet Has Changed the Nature of Talent

In previous generations, access to elite knowledge depended heavily on geography, institutional privilege, or economic background.

Today, a motivated student with:

a computer,
internet access,
curiosity,
and discipline

can study subjects that were once accessible only to specialists.

From graphics programming to AI, from computational physics to simulation engineering, the barriers are steadily falling.

This democratization of technical capability may become one of the defining developments of 21st-century India.

Intrinsic Motivation: The Real National Resource

Natural resources matter.

Infrastructure matters.

Capital matters.

But civilizations ultimately rise through motivated human beings.

Intrinsic motivation — the inner drive to learn, create, solve problems, and pursue truth without external reward — is the invisible force behind every scientific and technological revolution.

A nation that cultivates intrinsically motivated students will eventually produce innovators.

And innovators create industries.

Industries create economic power.

Economic power creates strategic independence.

Walking Alone Before Others Join

Every new idea initially appears isolated.

Every breakthrough begins with a small number of believers.

The message is simple:

do not wait for universal approval before beginning meaningful work.

Whether in science, software, engineering, entrepreneurship, or national development, progress often starts with individuals willing to move forward before the crowd understands the direction.

That is leadership.

And perhaps that is the deeper meaning of “walk alone.”

Because eventually, if the path is true, others follow.

Jai Hind... Jai Bharat...

Ancient Logic Meets Early AI: The Surprising Parallels Between Prolog and Sanskrit - Engineers of Bharat, wake up and embrace Sanskrit

Somenath Mukhopadhyay — Thu, 30 Apr 2026 03:48:00 +0000

When we think about Artificial Intelligence, we usually picture modern neural networks, GPUs, and massive datasets. But the intellectual roots of AI go much deeper—into symbolic reasoning, formal logic, and surprisingly, ancient linguistic traditions. One of the most fascinating comparisons is between early AI systems built using Prolog and the structure of Sanskrit, one of the oldest and most rigorously defined languages in human history.

This is not a superficial analogy. At a structural and philosophical level, both Prolog and Sanskrit share striking similarities in how they represent knowledge, rules, and inference.

1. Rule-Based Systems: Sutras vs Clauses

Early AI systems, especially those built in Prolog, rely heavily on rules and facts. A Prolog program is essentially a knowledge base composed of logical clauses:

Facts: Statements that are always true
Rules: Conditional relationships that derive new truths

Similarly, Sanskrit—especially as formalized by the ancient grammarian Pāṇini—is built on a system of sutras (rules). These are concise, highly optimized statements that define how words are formed and how grammar operates.

Both systems:

Encode knowledge as compact rules
Allow complex structures to emerge from simple primitives
Depend on rule application rather than procedural steps

In a sense, Pāṇini’s grammar can be viewed as one of the earliest known “programs.”

2. Declarative Nature

Prolog is a declarative language. You don’t tell the system how to solve a problem—you tell it what is true, and the system figures out the rest through logical inference.

Sanskrit grammar operates similarly:

It defines what constitutes valid language
It does not prescribe step-by-step generation in a procedural sense
Instead, valid expressions are derived through rule application

This declarative paradigm is fundamentally different from imperative programming—and both Prolog and Sanskrit embody it elegantly.

3. Pattern Matching and Unification

One of the core mechanisms in Prolog is unification —a process of matching patterns and binding variables to satisfy logical conditions.

Example (conceptually):

parent(X, Y) :- mother(X, Y).

The system tries to match patterns and infer relationships.

In Sanskrit:

Word formation and sentence construction involve pattern transformations
Roots (dhatus) combine with suffixes following strict matching rules
Morphological changes depend on context-sensitive patterns

This resembles a form of linguistic unification, where structures are matched and transformed based on rules.

4. Backtracking and Multiple Interpretations

Prolog uses backtracking to explore multiple possible solutions. If one path fails, it goes back and tries another.

Sanskrit, especially in classical literature:

Allows multiple valid interpretations of a sentence
Meaning can depend on context, case endings, and word order
Ambiguity is resolved through structured inference

While Sanskrit doesn’t “execute” backtracking computationally, its structure supports multi-path interpretation , similar to logical exploration in Prolog.

5. Compositionality and Generative Power

Both systems are highly compositional :

In Prolog, small rules combine to solve complex problems
In Sanskrit, small grammatical units combine to generate vast expressive possibilities

This compositional nature leads to:

Scalability of expression
Elegant reuse of rules
High generative capacity from limited primitives

6. Knowledge Representation

Prolog was designed for symbolic AI , where knowledge is explicitly represented and reasoned about.

Sanskrit, particularly in philosophical and scientific texts:

Encodes knowledge in a structured, rule-based format
Maintains clarity and precision in meaning
Supports logical discourse in fields like mathematics, astronomy, and philosophy

This makes Sanskrit not just a language, but a knowledge representation system.

7. Minimalism and Compression

Pāṇini’s grammar is famous for its extreme brevity. Rules are compressed using meta-rules, recursion, and symbolic shorthand.

Prolog also encourages:

Minimal representations
Reusable logic
Compact expression of complex relationships

Both systems aim for maximum expressiveness with minimal redundancy —a hallmark of elegant design.

8. Philosophical Foundations

At a deeper level, both Prolog and Sanskrit emerge from traditions that value:

Logic over procedure
Structure over execution
Inference over instruction

Prolog comes from formal logic and computational theory. Sanskrit emerges from a philosophical tradition deeply concerned with language, meaning, and cognition.

The convergence is not accidental—it reflects a shared pursuit of modeling intelligence through structure.

Conclusion: Rediscovering Intelligence Through Structure

Modern AI has largely shifted toward data-driven approaches like deep learning. But the comparison between Prolog and Sanskrit reminds us of an alternative vision of intelligence—one rooted in rules, logic, and symbolic reasoning.

For developers, linguists, and AI researchers, this intersection offers a powerful insight:

Intelligence is not just about learning patterns from data—it is also about representing and manipulating knowledge with precision.

In that sense, ancient Sanskrit and early AI are not distant domains—they are parallel explorations of the same fundamental question:

How can structured rules give rise to intelligent behavior?

If we revisit these ideas with modern tools, we may find that the future of AI is not just in neural networks—but also in rediscovering the elegance of symbolic systems that civilizations mastered thousands of years ago.

Let’s make this concrete with a small Prolog program , and then examine it through the lens of Sanskrit grammar and structure —not as a metaphor, but as a structural comparison.

🔹 A Simple Prolog Program

% Facts
father(ram, shyam).
father(ram, sita).
mother(gita, shyam).
mother(gita, sita).

% Rule
parent(X, Y) :- father(X, Y).
parent(X, Y) :- mother(X, Y).

% Rule for sibling relationship
sibling(X, Y) :- parent(Z, X), parent(Z, Y), X \= Y.

What this program does:

Defines facts about family relationships
Defines rules to infer:

Example query:

?- sibling(shyam, sita).

Output:

true.

Now: Analysis Through the Lens of Sanskrit

We’ll map key Prolog concepts to structural principles found in Sanskrit, especially in the grammatical system of Pāṇini and his work, the Ashtadhyayi.

1. Facts as “Pratijñā” (Given Truths)

In Prolog:

father(ram, shyam).

This is an atomic truth.

In Sanskrit:

This resembles a semantic assertion , like:

In the Paninian system:

Such statements are not “computed”
They are accepted inputs to the system

👉 Parallel:

Prolog facts = Given semantic truths (pratijñā-like statements)

2. Rules as Sutras (सूत्र)

Prolog rule:

parent(X, Y) :- father(X, Y).

This reads:

X is a parent of Y if X is a father of Y

In Sanskrit grammar:

A sutra defines transformation or classification rules
Example idea (not literal):

👉 Both share:

Conditional structure
Minimal expression
High reuse

👉 Key insight:

Prolog rules behave like generative sutras —they don’t store outcomes, they define how to derive them

3. Variables as “Anubandha” (Markers / Placeholders)

In Prolog:

parent(X, Y)

X and Y are placeholders

In Sanskrit grammar:

Pāṇini uses markers (anubandhas) and abstract symbols
These are not actual words but meta-linguistic variables

👉 Parallel:

Prolog variables ≈ Paninian symbolic placeholders

They:

Do not carry meaning themselves
Gain meaning through substitution

4. Unification vs Sandhi / Morphological Matching

Prolog uses unification :

It tries to match:

parent(Z, X), parent(Z, Y)

In Sanskrit:

Word formation uses rule-based matching
Example:

👉 Parallel:

Prolog unification ≈ rule-based linguistic matching

Both systems:

Depend on pattern compatibility
Apply transformations only when constraints are satisfied

5. Backtracking vs Interpretive Flexibility

In Prolog:

If one rule fails, it backtracks and tries another

In Sanskrit:

A sentence can allow multiple valid parses
Meaning emerges from:

Example:

Word order is flexible, but meaning is preserved via rules

👉 Parallel:

Prolog backtracking ≈ multi-path interpretation in Sanskrit parsing

6. The Sibling Rule as a Composite Sutra

sibling(X, Y) :- parent(Z, X), parent(Z, Y), X \= Y.

This is powerful:

It composes multiple rules
Introduces a constraint

In Sanskrit:

Complex constructions emerge from:

👉 This resembles:

compound rule application (samāsa-like compositionality)

7. Negation Constraint (X = Y)

This part:

X \= Y

Means:

X and Y must be different

In Sanskrit:

There are blocking rules (नियम / प्रतिबंध)
Certain forms are prevented under specific conditions

👉 Parallel:

Logical negation ≈ grammatical restriction rules

8. Knowledge Emergence

Important insight:

Nowhere did we explicitly define:

sibling(shyam, sita).

Yet it emerges.

In Sanskrit:

Infinite valid sentences are generated from:

👉 Both systems:

Are generative, not enumerative

Deep Insight: Computation vs Derivation

Concept	Prolog	Sanskrit
Knowledge	Stored as facts	Encoded via roots & meanings
Rules	Logical clauses	Sutras
Execution	Query resolution	Derivation (prakriya)
Engine	Backtracking search	Rule ordering + constraints
Output	Logical truth	Valid linguistic expression

Final Thought

If you look carefully, this Prolog program is not “code” in the modern imperative sense.

It is closer to a derivation system —and that is exactly what Sanskrit grammar is.

👉 Both answer the same deep question:

How can a finite set of rules generate an infinite space of valid structures?

That’s why many researchers—from early AI pioneers to modern computational linguists—have seen Sanskrit not just as a language, but as a formal system of knowledge representation , remarkably aligned with symbolic AI like Prolog.

Read ON...

knowledge representation in Sanskrit and AI.pdf - Google Drive

drive.google.com

Active Object Design Pattern, implemented using Julia - from Active Object paradigm of Symbian S60 to today's journey in Julia

Somenath Mukhopadhyay — Fri, 17 Apr 2026 10:36:00 +0000

The Active Object Design Pattern is a concurrency pattern that decouples method invocation from method execution, allowing tasks to run asynchronously without blocking the caller.

At its core, an Active Object introduces a proxy that clients interact with. Instead of executing methods directly, the proxy places requests into a queue. A separate worker thread (or pool) processes these requests in the background. This creates a clean separation between what needs to be done and when/how it gets executed.

A typical Active Object system has four key components:

Proxy – exposes the interface to the client
Method Request – encapsulates a function call as an object or callable
Activation Queue – holds pending requests
Scheduler/Worker – executes requests asynchronously

This pattern is especially useful when:

You want to avoid blocking the main thread
You need controlled concurrency (e.g., limited worker threads)
You want to serialize access to shared resources safely

Here's a simple implementation of Active Object Design Pattern in Julia.

function ThreadedActiveObject(nworkers=4)
    ch = Channel{Function}(32)
    tasks = []

    for _ in 1:nworkers
        push!(tasks, Threads.@spawn begin
            for job in ch
                Base.invokelatest(job)
            end
        end)
    end

    return ch, tasks
end

function heavy_compute(n)
    s = 0.0
    for i in 1:n
        s += sin(i) * cos(i)
    end
    println("Computed sum for $n = $s on thread $(Threads.threadid())")
end

ao, tasks = ThreadedActiveObject(4)

for i in 1:10
    put!(ao, () -> heavy_compute(10^7 + i))
end

close(ao)
foreach(wait, tasks)

Sequence Diagram:

Mapping The Code to Active Object Components

Let’s reinterpret the code piece by piece.

Proxy (Client Interface)


put!(ao, () -> heavy\_compute(10^7 + i))

This is the proxy layer.

Why?

The caller is not executing the method directly
Instead, it:
- wraps the request as a function (closure)
- submits it to a queue

In classic Active Object:


proxy.method\_call() → enqueue request

In my code:


put!(ao, job\_function)

So:

The Channel (ao) acts as the proxy interface

Activation Queue


ch = Channel{Function}(32)

This is the Activation Queue.

Holds pending method requests
Thread-safe
Decouples producer and consumer

Classic role:


Queue<Request>

My version:


Channel{Function}

Each Function = a method request object

Method Request


() -> heavy\_compute(10^7 + i)

This is a Method Request object , just expressed as a closure.

In traditional OO:


class PrintTask : MethodRequest {  
void execute() { ... }  
}

In Julia:


() -> heavy\_compute(10^7 + i)

Key idea:

Encapsulates:
- what to do
- data (i)
- logic

Scheduler + Servant (Worker Threads)


Threads.@spawn begin  
 for job in ch  
 Base.invokelatest(job)  
 end  
end

This block plays two roles :

Scheduler


for job in ch

Pulls requests from the queue
Decides execution order (FIFO here)

This is the scheduler

Servant


Base.invokelatest(job)

Actually executes the request

This is the servant

So each worker thread is:


[Scheduler + Servant]

Thread Pool (Multiple Active Objects Workers)


for \_ in 1:nworkers  
 Threads.@spawn ...  
end

Creates multiple workers
All consume from the same queue

This is a multi-threaded Active Object

Classic pattern often has:

1 thread → 1 active object

My version:

N threads → shared activation queue

This is more like:

Active Object + Thread Pool hybrid

Lifecycle Control

Closing the queue


close(ao)

Signals: no more requests
Workers stop after finishing remaining jobs

Waiting for completion


foreach(wait, tasks)

Ensures all scheduled work is completed

And here's my journey through the Symbian S60's Active Object paradigm - studied many years ago...

Active Object Symbian

A story on my checkered software journey through the wilderness of concurrent programming - one important lesson - basic idea...

Somenath Mukhopadhyay — Fri, 17 Apr 2026 05:20:00 +0000

There’s a certain kind of journey that doesn’t show up on résumés—the kind that winds through late nights, cryptic bugs, half-working abstractions, and those rare moments when something finally clicks. My journey through concurrent programming has been exactly that: a long walk through a wilderness where the landscape keeps changing, but the underlying terrain remains strangely familiar.

I started in the era of VC++. Back then, concurrency felt mechanical—almost industrial. I didn’t “design” concurrent systems; I wrestled them into submission. WAIT_FOR_SINGLE_OBJECT, WAIT_FOR_MULTIPLE_OBJECTS—these weren’t just API calls to me; they were survival tools. I learned quickly that a missed signal or a mishandled handle could freeze everything into a silent deadlock. Threads were powerful, yes—but also unforgiving. I treated them with respect because I had no choice.

Then I encountered Symbian, and with it, the idea of Active Objects. That was a turning point for me. Instead of manually juggling threads, I began thinking in terms of events, schedulers, and requests. The system was still concurrent, but the chaos felt… organized. I wasn’t blocking threads anymore; I was orchestrating asynchronous flows. It felt like moving from brute force to something more deliberate.

It wasn’t effortless, though. The Active Object model demanded discipline. I had to understand request lifecycles, callbacks, and the implicit contract with the scheduler. But once it clicked, it changed how I saw concurrency—not just as parallel execution, but as controlled responsiveness.

Then came Android and Java. By that time, concurrency had evolved into something more structured. Executors, thread pools, futures, synchronized blocks—the tools were richer, the abstractions deeper. I could finally express intent more clearly: run this task, schedule that work, wait for these results. The raw edges of thread management were softened.

But I also realized something important: the old problems never really went away. Deadlocks still happened. Race conditions still crept in. Performance was still a careful balancing act. The tools had improved, but the responsibility was still mine.

And then I found Julia.

Julia felt different from the start. Lightweight tasks, channels, @async, Threads.@spawn—it was concurrency with a kind of fluidity I hadn’t experienced before. I could write code that looked almost sequential, yet behaved concurrently. Channels made communication feel natural again.

I remember watching tasks communicate over a channel, work flowing across threads, and thinking—this feels like everything I’ve learned, coming together. The low-level discipline from VC++, the event-driven thinking from Symbian, the structured abstractions from Java—they were all there, just distilled into something simpler and more expressive.

That’s when the most important lesson became clear to me.

Across all these platforms, languages, and paradigms—the surface keeps changing. APIs evolve. Syntax improves. Abstractions come and go.

But the core idea doesn’t change.

At its heart, concurrent programming has always been about a few simple truths:

Work can happen independently.
Coordination is harder than execution.
Communication is everything.
And timing… timing is where things either work beautifully or fall apart.

Whether I’m waiting on a kernel object, scheduling an active request, submitting tasks to an executor, or passing messages through a channel—I’m solving the same fundamental problem. I’m managing time, state, and interaction.

The wilderness hasn’t disappeared for me. I’ve just learned how to navigate it.

And maybe that’s what this journey really is—not moving from one technology to another, but moving from confusion to clarity. From fighting concurrency… to understanding it.

Inter-thread communication in Julia - Channel and Wait-Notify...

Somenath Mukhopadhyay — Thu, 16 Apr 2026 02:55:00 +0000

There are a few ways we can accomplish inter-thread communication in Julia. In this article, we will look into two ways - via channel and via wait & notify.

Via Channel...

Here's an implementation of the Producer-Consumer problem in Julia using two threads. The producer creates and puts it in a channel, whereas the consumer takes it from the channel. The producer and consumer run in two different threads.


using Base.Threads

ch = Channel{Int}(10)

@sync begin

# Producer (runs on a thread)
    Threads.@spawn begin
        for i in 1:5
            println("Producing $i on thread $(threadid())")
            put!(ch, i)
            sleep(0.5)
        end
        close(ch)
    end

    # Consumer (runs on another thread)
    Threads.@spawn begin
        for val in ch
            println("Consuming $val on thread $(threadid())")
        end
    end

end

Let's try to dissect the above code.

The Key Idea: Channels are Iterable Streams

In Julia, a Channel is not just a queue—it implements the iteration protocol.

So when we write:

for val in ch
    println("Consuming $val on thread $(threadid())")
end

this is conceptually equivalent to:

while true
    val = take!(ch) # blocks if empty
    println("Consuming $val on thread $(threadid())")
end

…but with one crucial addition:

The loop automatically stops when the channel is closed.

What Actually Happens Internally

When Julia executes:

for val in ch

it translates roughly into:

state = iterate(ch)

while state !== nothing
    (val, next_state) = state
    println(...)
    state = iterate(ch, next_state)
end

For Channel, iterate(ch) is defined such that:

It internally calls take!(ch)
If data is available → returns (value, state)
If the channel is:

Why This is Perfect for Concurrency

Let’s break down the behavior in your example:

Producer Thread

put!(ch, i)

Pushes data into the channel
If the channel buffer is full → producer blocks

Consumer Thread

for val in ch

If data is available → consumes immediately
If empty → consumer blocks (non-busy wait!)
If channel is closed → loop exits cleanly

Important: This is NOT Busy Waiting

A common mistake in other languages:

while(queue.empty()) { /* spin */ }

But Julia does this instead:

The consumer yields control
The scheduler runs another task
When put! happens → consumer is resumed

This is cooperative scheduling , not CPU spinning.

Why `for val in ch` is Better Than `take!` Loop

We could write:

while true
    val = take!(ch)
    println(val)
end

But then we must manually handle termination:

How do we know when to stop?
We'd need a sentinel value or extra signaling

With:

for val in ch

we get:

Automatic blocking
Automatic wake-up
Automatic termination on close(ch)
Cleaner, declarative code

The Role of `close(ch)`

This line in our producer is critical:

close(ch)

Without it:

The consumer will wait forever
Because it assumes more data might come

With it:

The iteration ends naturally
for loop exits → task completes

Subtle but Important Detail

Even though we used:

Threads.@spawn

The channel itself is thread-safe , meaning:

Multiple producers/consumers can safely operate
Synchronization is handled internally

Final Insight

Consumer code:

for val in ch

is not just syntactic sugar—it encodes three things at once:

Blocking synchronization (wait for data)
Data flow semantics (consume stream)
Termination protocol (stop on close)

That’s why it’s considered idiomatic Julia concurrency.

Via Event/Condition

This is pretty good for implementing signalling between threads.

Here's the code for such a system.


using Base.Threads

mtx = ReentrantLock()
cond = Base.GenericCondition(mtx)   #bind lock + condition

@sync begin
    Threads.@spawn begin
        for i in 1:5
            println(i)
            sleep(1)
        end

        println("Now Waiting on a condition and will wake up only when that condition will be signalled...")

        lock(mtx) do
            wait(cond)   #correct lock
        end

        println("Now again Resuming!")

        for j in 6:10
            println(j)
            sleep(1)
        end
    end

    sleep(10)

    lock(mtx) do
        notify(cond)     #SAME lock
    end
end

Core Idea

A Condition in Julia is a wait queue tied to a lock.

Threads can:

wait(cond) → sleep until signaled
notify(cond) → wake waiting thread(s)

What happens in the code?

Prints numbers 1 → 5
Acquires lock and calls:
Internally:
- Releases mtx
- Goes to sleep
- Gets queued on cond

The thread is now blocked without consuming CPU

Main Thread (Producer / Notifier)


sleep(10)  

lock(mtx) do  
 notify(cond)  
end

What happens:

After 10 seconds, main thread:
- Acquires the same lock (mtx)
- Calls notify(cond)
This:
- Wakes the waiting thread
- That thread re-acquires the lock
- Continues execution

Execution Timeline


Worker Thread Main Thread  
-------------- -------------  
1 → 5 printed  
Now Waiting...  
(wait → sleep)  

 sleep(10)  
 notify(cond)  

Resuming!  
6 → 10 printed

Critical Rules

1. Lock must be held

Both must be inside:


lock(mtx) do ... end

Otherwise:


ConcurrencyViolationError("lock must be held")

Same lock everywhere


cond = GenericCondition(mtx)

👉 You must use this exact mtx for:

wait
notify

`wait` is atomic

When calling:


wait(cond)

Julia:

Releases lock
Sleeps
On notify → wakes up
Re-acquires lock

This avoids race conditions

Conceptual Model

Think of it like:


Condition = Lock + Queue of waiting threads

wait → join queue
notify → wake one (or all)

When to use this?

Use Condition variables when:

You need pure signaling
No data needs to be transferred

Use Channel when:

You need data + synchronization

@async in Julia is not parallelism - but @Thread.spawn is...

Somenath Mukhopadhyay — Wed, 15 Apr 2026 12:12:00 +0000

The Core Idea

In Julia , @async gives you concurrency , not parallelism.

@async → runs multiple tasks, but on the same thread
Threads.@spawn → runs tasks on multiple CPU threads (true parallelism)

Demonstration 1

function task(name)
     println("$name running on thread ", Threads.threadid())
     sleep(1)
     println("$name finished on thread ", Threads.threadid())
 end

 @sync begin
     @async task("Task A")
     @async task("Task B")
 end

If we run the above code, we will get

Task A running on thread 1

Task B running on thread 1

Task A finished on thread 1

Task B finished on thread 1

What is happening internally?

Julia uses cooperative scheduling for @async:

Tasks yield control (e.g., sleep, I/O)
Scheduler switches between them
But execution remains on one OS thread

As you can see from the output, both tasks are running on the same thread.

Demonstration 2

#parallelism using multiple Threads

function task(name)
    println("$name running on thread ", Threads.threadid())
    sleep(1)
    println("$name finished on thread ", Threads.threadid())
end

@sync begin
    Threads.@spawn task("Task A")
    Threads.@spawn task("Task B")
end

If we run the above code, we will get

Task B running on thread 3

Task A running on thread 4

Task B finished on thread 3

Task A finished on thread 4

As you can see from the output, two threads are running in parallel.

Summary

Feature	`@async`	`Threads.@spawn`
Threads used	Single thread	Multiple threads
Parallelism	No	Yes
Concurrency	Yes	Yes
Best for	I/O, networking	CPU-heavy tasks
Scheduling	Cooperative	Preemptive (OS threads)

IPC - Incremental Potential Contact - implemented using Julia...

Somenath Mukhopadhyay — Sun, 12 Apr 2026 07:39:00 +0000

Scientists have started noticing Julia.

The word spreads.

Not through a marketing campaign.

But seeing the Python-like ease of code writing, along with the speed of C++.

Physicists liked that Julia felt like writing equations.
Engineers liked that it handled performance without boilerplate.
Researchers loved that they could:

. Prototype quickly
. Scale to HPC when needed
. Avoid rewriting everything in another language

The two-language problem vanished.

A prototype can be scaled to a production stage without much effort.

I am loving it.

I studied Incremental Potential Contact (IPC) some time ago and implemented it in Python. Today I used Julia to explore IPC.

Here's the visualization.

And here's the source code...

using LinearAlgebra
using Plots
using Printf

# -------------------------------
# IPC-like Force (Barrier-inspired)
# -------------------------------
function ipc_force(p0::Vector{Float64}, p1::Vector{Float64},
                   kappa::Float64, d_hat::Float64)

    diff = p1 - p0
    d = norm(diff)

    eps = 1e-6
    d_safe = max(d, eps)

    if d >= d_hat
        return zeros(3), zeros(3)
    end

    # Barrier-like force
    f_mag = kappa * (1 / d_safe - 1 / d_hat)

    n = diff / d_safe

    f0 =  f_mag * n
    f1 = -f0

    return f0, f1
end


# -------------------------------
# Simulation Core
# -------------------------------
function simulate(; dt=0.002, steps=500,
                    kappa=1.0, d_hat=0.02, mass=1.0)

    p0 = [-0.02, 0.0, 0.0]
    p1 = [ 0.02, 0.0, 0.0]

    # 🔥 stronger motion
    v0 = [0.5, 0.0, 0.0]
    v1 = [-0.5, 0.0, 0.0]

    traj0 = Vector{Vector{Float64}}()
    traj1 = Vector{Vector{Float64}}()
    distances = Float64[]

    push!(traj0, copy(p0))
    push!(traj1, copy(p1))
    push!(distances, norm(p1 - p0))

    for step in 1:steps
        f0, f1 = ipc_force(p0, p1, kappa, d_hat)

        v0 += dt * f0 / mass
        v1 += dt * f1 / mass

        # ✅ ADD DAMPING HERE
        damping = 0.99
        v0 *= damping
        v1 *= damping

        p0 += dt * v0
        p1 += dt * v1

        d = norm(p1 - p0)

        @printf("Step %d: distance = %.6f\n", step, d)

        push!(traj0, copy(p0))
        push!(traj1, copy(p1))
        push!(distances, d)
    end

    return traj0, traj1, distances
end

# -------------------------------
# Visualization (Animation + Graph)
# -------------------------------
function visualize(traj0, traj1, distances; dt=0.0002,
                   filename="ipc_simulation.gif")

    time = collect(0:dt:dt*(length(distances)-1))

    anim = @animate for i in 1:length(traj0)

        pos0 = traj0[i]
        pos1 = traj1[i]

        # ---- LEFT: particle motion ----
        p1_plot = scatter(
            [pos0[1], pos1[1]],
            [pos0[2], pos1[2]],
            xlim=(-0.03, 0.03),
            ylim=(-0.02, 0.02),
            markersize=8,
            label="Particles",
            title="IPC Collision Avoidance"
        )

        plot!(
            [pos0[1], pos1[1]],
            [pos0[2], pos1[2]],
            label="distance"
        )

        # ---- RIGHT: distance vs time ----
        p2_plot = plot(
            time[1:i],
            distances[1:i],
            xlabel="Time",
            ylabel="Distance",
            title="Distance vs Time",
            label="d(t)"
        )

        hline!([0.02], linestyle=:dash, label="d_hat")

        # ---- Combine both ----
        plot(p1_plot, p2_plot, layout=(1,2), size=(900,400))
    end

    gif(anim, filename, fps=30)
end


# -------------------------------
# Main
# -------------------------------
function main()
    println("Running IPC simulation with diagnostics...")

    traj0, traj1, distances = simulate()

    println("Generating animation with distance plot...")

    visualize(traj0, traj1, distances)

    println("Done. Check ipc_simulation.gif")
end


# Run
main()

Here's my earlier investigation of IPC (using Python)...

(https://som-itsolutions.blogspot.com/2025/10/incremental-potential-contact-ipc.html)

Happy code digging...

Half Sync - Half Async design pattern implemented using Julia...

Somenath Mukhopadhyay — Wed, 08 Apr 2026 14:11:00 +0000

My deep study of the Android AsyncTask framework many years ago - a perfect example of this design pattern by bright Google engineers...

Half Sync - Half Async

# The Julia Code
struct Task
    id::Int
    payload::Float64
end

function worker(id, ch::Channel)
    for task in ch
        println("Worker $id processing Task $(task.id)")
        result = sum(sin.(1:10^6 .* task.payload))
        println("Worker $id finished Task $(task.id)")
    end
    println("Worker $id shutting down")
end

function async_producer(ch::Channel, n::Int)
    for i in 1:n
        sleep(rand())
        println("Producing Task $i")
        put!(ch, Task(i, rand()))
    end
    close(ch)
end

function run_system(num_tasks=10, num_workers=4)
    ch = Channel{Task}(32)

    @sync begin
        # Producer runs as async task tracked by @sync
        @async async_producer(ch, num_tasks)

        # Workers
        for i in 1:num_workers
            Threads.@spawn worker(i, ch)
        end
    end
end

run_system(20, Threads.nthreads())

1. The Pattern Refresher

Half-Sync/Half-Async splits a system into:

🔹 Async Layer

Non-blocking
Event-driven
Produces work

🔹 Sync Layer

Blocking / CPU-bound
Deterministic execution
Processes work

🔹 Boundary

A queue (here: Channel)
Decouples the two layers

2. Mapping The Code to the Pattern

🔸 (A) Boundary → `Channel`

ch = Channel{Task}(32)

This is the core of the pattern.

👉 It acts as:

A thread-safe queue
A decoupling buffer
A synchronization boundary

Interpretation:

“Async world hands off work to Sync world through a controlled interface.”

(B) Async Layer → `async_producer`

@async async_producer(ch, num_tasks)

Inside:

for i in 1:n
    sleep(rand())
    put!(ch, Task(i, rand()))
end
close(ch)

Why this is “Async”:

@async → cooperative scheduling (non-blocking)
sleep(rand()) → simulates unpredictable external events
put! → hands off work without doing computation

Conceptual role:

“I don’t process. I just observe and emit events.”

(C) Sync Layer → `worker`

Threads.@spawn worker(i, ch)

Inside:

for task in ch
    result = sum(sin.(1:10^6 .* task.payload))
end

Why this is “Sync”:

take! (via for task in ch) → blocking
CPU-heavy computation
Runs on real OS threads

Conceptual role:

“Give me work. I will process it fully and deterministically.”

(D) Coordination → `@sync`

@sync begin
    @async async_producer(...)
    Threads.@spawn worker(...)
end

This is not part of the original pattern per se, but in Julia it ensures:

The system behaves like a long-running service
Main thread waits for both layers

3. End-to-End Flow (Pattern in Action)

Step-by-step:

Async Layer wakes up
Task is enqueued
Sync Layer pulls work
Processing happens
Repeat until channel closes

4. Why This is Half-Sync/Half-Async (Not Just Threads)

Because of strict separation of concerns :

Concern	Where handled
Event timing	Async layer
Work queueing	Channel
Execution	Sync layer

👉 The producer never processes

👉 The worker never generates events

That separation is the essence of the pattern

5. Key Properties The Code Achieves

Decoupling

Producer speed ≠ Worker speed
Buffered via Channel(32)

Backpressure

If workers are slow → channel fills → put! blocks
Natural flow control

Scalability

Threads.@spawn worker(i, ch)

Increase workers → parallelism increases

Clean Shutdown

close(ch)

Workers exit automatically via:

for task in ch

6. Subtle but Deep Insight

The system is not just parallel — it is:

A streaming system with a controlled execution boundary

This is exactly how:

High-performance servers
Simulation engines
Data pipelines

are designed internally.

Structured Concurrency in Julia: A Clean Approach Using @sync and Threads.@spawn

Somenath Mukhopadhyay — Wed, 08 Apr 2026 06:19:00 +0000

Concurrency is often introduced with complexity—locks, counters, race conditions, and subtle bugs. But Julia offers a refreshing alternative: structured concurrency , where parallel execution is expressed clearly and safely.

Let’s explore this concept through a simple, elegant example.

The Scenario

We simulate three students—Ridit, Ishan, and Manav—each working on a task that takes a different amount of time.

Instead of executing these tasks sequentially, we want them to run in parallel , and then proceed only when all are complete.

The Code:


function student_task(name::String, seconds::Real)
    println(name, " is starting the task")
    sleep(seconds)
    println(name, " has finished the task")
    return seconds
end

@sync begin
    # Run with: julia --threads=4   (or any number > 1)
    ridit = Threads.@spawn student_task("Ridit", 10.0)
    ishan = Threads.@spawn student_task("Ishan", 15.0)
    manav = Threads.@spawn student_task("Manav", 20.0)

    println("Ridit took ", fetch(ridit), " seconds")
    println("Ishan took ", fetch(ishan), " seconds")
    println("Manav took ", fetch(manav), " seconds")
end

println("Now as all of the students have finished the task, the invigilator will leave")

Breaking It Down

1. Task Definition

student_task(name::String, seconds::Real)

Each task:

Announces when it starts
Sleeps for a given duration (simulating work)
Announces completion
Returns the time taken

This is a stand-in for any real workload—simulation steps, I/O operations, or compute-heavy routines.

2. Parallel Execution with `Threads.@spawn`

ridit = Threads.@spawn student_task("Ridit", 10.0)

Threads.@spawn launches a task asynchronously
Julia schedules it across available CPU threads
Returns a Task handle immediately

All three students start working concurrently , not one after another.

3. Synchronization with `@sync`

@sync begin
    ...
end

This is the centerpiece.

@sync waits for all spawned tasks inside its block to complete
It automatically tracks these tasks—no manual counting required

This is structured concurrency in action:

The lifetime of tasks is tied to the scope in which they are created.

4. Fetching Results Safely

fetch(ridit)

Retrieves the result of the task
If the task is not finished, it blocks until completion

Even though tasks run in parallel, fetch ensures correctness.

Execution Behavior

The tasks take:

Ridit → 10 seconds
Ishan → 15 seconds
Manav → 20 seconds

Because they run concurrently:

Total runtime ≈ 20 seconds , not 45 seconds

This is the key benefit: time compression via parallelism.

Structured Concurrency vs Traditional Approaches

In many languages, you would need:

Counters (like latches)
Explicit joins
Manual bookkeeping

Here, Julia abstracts that away.

Traditional thinking:

“Track how many tasks are left.”

Julia thinking:

“Everything started here must finish before leaving.”

This shift reduces:

Bugs
Cognitive load
Boilerplate code

Final Insight

This small example captures a powerful idea:

Concurrency should be structured, not improvised.

With @sync and Threads.@spawn, Julia gives you:

Clarity of intent
Safety by design
Performance with simplicity

The suits vs engineers problem - the lesson...

Somenath Mukhopadhyay — Sun, 22 Mar 2026 08:52:00 +0000

IBM built Deep Blue, a specialized chess supercomputer.

In the historic Kasparov vs Deep Blue 1997, Deep Blue won the match 3.5–2.5.

It was the first time a reigning world champion lost to a computer under standard tournament conditions.

But interestingly, Deep Blue was not “AI” in the modern sense.

It mainly relied on:

Massive brute-force search (millions of chess positions per second)

Expert-crafted evaluation functions

Special hardware chips for chess calculations

Now let's come back to the point.

During the early decades, IBM was extremely engineering-driven. Its research labs produced major breakthroughs:

IBM System/360 — one of the most influential computer platforms ever built

Hard-disk storage technology

RISC processor research

The chess supercomputer IBM Deep Blue

But in the late 1980s–1990s, IBM faced huge competition from cheaper personal computers and software companies.

Then...

Bureaucracy increased

Decision-making shifted toward business managers

Risk-taking in engineering declined

The moment suits started dominating engineering, it's all over for IBM.

Always remember great technology companies are built by engineers but often slowly taken over by managers.

The healthiest companies try to keep technical leadership at the top.

Think about Elon Musk and his companies.

Think about NVIDIA.

Think about modern AI based giants.

These are all engineer driven.

Will sometimes in the future, they all will travel the same path as IBM?

Let's keep our fingers crossed...

Only time will be able to answer this...

DEV Community: Somenath Mukhopadhyay

Class level locking in C++ - serializing multiple threads...

Why Use std::lock_guard?

Why Use std::async?

Final Thoughts

Class Level Locking in Java - inspired by Android's AsyncTask implementation - serializing multiple threads...

1. What Exactly Is Happening Here?

2. Understanding the Synchronization

3. Flow of Execution

Step-by-step

4. What Happens When Threads Run?

5. Runtime Behavior

6. Why This Is Called "Class-Level Locking"

7. Why Static Matters

8. Relationship to Android AsyncTask

Shared Static Executor

Synchronized Method

Result

9. Why Android Did This

10. Deeper JVM Insight

11. Why Studying Open Source Code Is Important

Theory vs Reality

12. Why Great Engineers Read Source Code

13. What You Are Actually Learning Here

Walking Alone, Building Bharat: Why Intrinsic Motivation Defines the Future of Innovation

The Rise of a New Bharat

From Examination Factories to Knowledge Civilization

A Small Example of a Bigger Transformation

The Internet Has Changed the Nature of Talent

Intrinsic Motivation: The Real National Resource

Walking Alone Before Others Join

Ancient Logic Meets Early AI: The Surprising Parallels Between Prolog and Sanskrit - Engineers of Bharat, wake up and embrace Sanskrit

1. Rule-Based Systems: Sutras vs Clauses

2. Declarative Nature

3. Pattern Matching and Unification

4. Backtracking and Multiple Interpretations

5. Compositionality and Generative Power

6. Knowledge Representation

7. Minimalism and Compression

8. Philosophical Foundations

Conclusion: Rediscovering Intelligence Through Structure

🔹 A Simple Prolog Program

What this program does:

Now: Analysis Through the Lens of Sanskrit

1. Facts as “Pratijñā” (Given Truths)

2. Rules as Sutras (सूत्र)

3. Variables as “Anubandha” (Markers / Placeholders)

4. Unification vs Sandhi / Morphological Matching

5. Backtracking vs Interpretive Flexibility

6. The Sibling Rule as a Composite Sutra

7. Negation Constraint (X = Y)

8. Knowledge Emergence

Deep Insight: Computation vs Derivation

Final Thought

knowledge representation in Sanskrit and AI.pdf - Google Drive

Active Object Design Pattern, implemented using Julia - from Active Object paradigm of Symbian S60 to today's journey in Julia

Sequence Diagram:

Mapping The Code to Active Object Components

Proxy (Client Interface)

Why?

Activation Queue

Method Request

Scheduler + Servant (Worker Threads)

Scheduler

Servant

Thread Pool (Multiple Active Objects Workers)

Lifecycle Control

Closing the queue

Waiting for completion

A story on my checkered software journey through the wilderness of concurrent programming - one important lesson - basic idea...

Inter-thread communication in Julia - Channel and Wait-Notify...

Via Channel...

The Key Idea: Channels are Iterable Streams

What Actually Happens Internally

Why This is Perfect for Concurrency

Producer Thread

Consumer Thread

Important: This is NOT Busy Waiting

Why for val in ch is Better Than take! Loop

The Role of close(ch)

Why `for val in ch` is Better Than `take!` Loop

The Role of `close(ch)`

`wait` is atomic

🔸 (A) Boundary → `Channel`

(B) Async Layer → `async_producer`

(C) Sync Layer → `worker`

(D) Coordination → `@sync`

2. Parallel Execution with `Threads.@spawn`

3. Synchronization with `@sync`