DEV Community: Somenath Mukhopadhyay

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...

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.

With the fall of Windows and the rise of Linux, Computer Science is gradually crawling back to its most rightful community...

Somenath Mukhopadhyay — Fri, 13 Mar 2026 04:00:00 +0000

1. The “Windows era” of computing

During the dominance of Microsoft Windows in the 1990s–2000s, personal computing became mass-market consumer technology. The focus shifted toward:

Ease of use
Graphical interfaces
Office productivity
Gaming and consumer software

Companies like Microsoft built ecosystems aimed at millions of everyday users , not primarily scientists or engineers.

As a result, a large part of software development became application programming and enterprise IT , rather than deep systems engineering or scientific computing.

2. Linux and the return of engineering culture

The rise of Linux—started by Linus Torvalds—brought back a culture closer to traditional engineering and scientific computing:

Open source collaboration
Systems-level programming
High-performance computing
Research computing environments

Today, Linux dominates areas like:

Supercomputers (almost all of them run Linux)
Scientific computing clusters
Cloud infrastructure
AI/ML systems

Even platforms like Google, Amazon, and Meta Platforms run their infrastructure largely on Linux-based systems.

3. The deeper historical perspective

Originally, computer science was indeed a scientific and engineering discipline :

Numerical simulations
Physics modeling
Aerospace computing
Mathematical computation

Think of fields like:

Computational Physics
Computational Fluid Dynamics
Scientific Computing

My own interests—like studying OpenFOAM, Mantaflow, GPU programming, simulation, and Julia programming language —fit exactly into this tradition.

4. What is really happening

A better description might be:

Consumer computing and engineering computing are diverging again.

Consumer layer → mobile apps, web, AI tools
Engineering layer → Linux, HPC, simulation, GPUs

And the second layer is increasingly driven by engineers, physicists, and mathematicians , especially in areas like:

simulation
AI
computational science
scientific visualization

Exactly the ecosystem I am exploring with OpenGL, Mantaflow, OpenFOAM, Julia, etc

💡 A deeper observation:

The biggest shift is not Windows → Linux.

It is “Software as product” → “Computation as science and infrastructure.”

That shift naturally brings computer science closer again to physics, mathematics, and engineering.

From My Computer to This PC - you will own nothing and be happy - the rise and fall of Windows PC...

Somenath Mukhopadhyay — Thu, 12 Mar 2026 13:53:00 +0000

1. The Era of “My Computer” (1980s–2000s)

The early PC era was about personal ownership and control.

Companies like

Microsoft
IBM
Intel

created a system where:

You bought hardware
You installed software locally
Your files lived on your machine

Operating systems like:

Windows 95
Windows XP

reinforced the concept of “My Computer.”

You had:

Local control
Offline capability
Permanent ownership of software licenses

This was the golden age of personal computing sovereignty.

2. The Shift Begins (2010s)

The model started changing.

Major shifts:

Cloud Computing

Platforms like:

Microsoft Azure
Google Drive
Dropbox

moved data from personal machines to remote servers.

Software Subscriptions

Traditional purchase → subscription model

Example:

Microsoft Office → Microsoft 365

You no longer own the software — you rent it.

3. The Rise of Platform Lock-In

Modern ecosystems increasingly control the user environment.

Examples:

Windows 11 requiring Microsoft accounts
Cloud-based authentication
Telemetry and data collection

The PC becomes less independent and more connected to corporate infrastructure.

4. The New Model: “Your Computer Is a Terminal”

The trend now is toward:

Cloud desktops
Streaming applications
Web-based software

Examples:

Windows 365 (Cloud PC)
Google ChromeOS

In these systems:

Your apps run in the cloud
Your data lives on company servers
Your device becomes just an access terminal

5. The Counter-Movement

Many technologists push back with open and local computing.

Alternatives include:

Linux
FreeCAD
Blender

These emphasize:

Local ownership
Open source transparency
Offline capability

Interestingly, my own interest in FreeCAD, OpenGL, and simulation sits squarely in this “sovereign computing” movement.

6. The Big Question

The future may split into two computing worlds :

Consumer world

Cloud apps
Subscriptions
Locked ecosystems

Engineering / research world

Local computing power
Open software
Full system control

High-end engineering (CFD, simulation, graphics) still needs local compute sovereignty.

In short:

The PC is evolving from “my computer” → “their platform.”

But in domains like simulation, graphics, and scientific computing , the traditional power-user PC is far from dead.

Usefulness of Julia in engineering syllabus - we must include it in the engineering curriculum...

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

Hey guys... today I want to write about the basic hindrance of engineering college studies. You know the problem - modern-day industries want engineers who can code, who are right at the juncture of engineering and software. Engineering education is beyond just a few theories, complex mathematical formulae, and examinations to test you on such areas. It's also about visualizing and simulating the results of such theories.

So far, the system in engineering colleges is somewhat like

MATLAB for modeling
Python for data
C++ for performance
Simulink for block diagrams

And now comes the Julia... it collapses all these layers.

You can:

Write high-level control logic
Drop to numerical linear algebra
Move into differential equation solvers
Even implement custom integrators

All in one language...

With sophisticated libraries in Julia, like differentialequations.jl and many such, the engineers have got the right tool for modelling and visualizing the maths and engineering problems...

Let's welcome Julia to the engineering colleges.

Today I was playing around with my college days' engineering education, namely RLC circuits, and found how Julia can transform it through intuitive visualization of the output - a damped waveform. We can visualize the output waveform by varying R, L, and C, yielding a powerful visual tool for a better understanding of basic circuitry theorems.

Here's the video of today's Julia experimentation - RLC series circuit...

Fig 1: RLC series circuit visualization

And here's the simulation of an RLC parallel circuit.

Fig 2: RLC parallel circuit simulation

I hope Julia transforms itself from a niche area of scientific modelling and simulation tools into a larger ecosystem of software - SciML is already happening...

A Simple Cloth Simulation in Julia — Inspired by My Son’s Blender Experiments

Somenath Mukhopadhyay — Fri, 06 Mar 2026 11:52:00 +0000

Four years ago, I watched my son Ridit, in class V back then, experimenting with cloth and soft-body simulations in Blender. At that time, he was deeply interested in learning how modern graphics tools simulate physical behaviour such as cloth, smoke, and rigid body dynamics.

One of his experiments is captured in this video:

Watching him explore Blender’s simulation tools sparked a thought in my mind:

Could I reproduce a simplified cloth simulation myself using code?

Years later, while exploring scientific computing with Julia , I decided to attempt exactly that.

The result is a small but interesting Verlet-integration based cloth simulation written entirely in Julia.

Why Verlet Integration?

In physics simulations used in games and graphics engines, Verlet integration is very popular because:
• It is simple

• It is numerically stable

• It does not explicitly require velocity storage

Many cloth simulators in early game engines relied on this technique.

The basic idea is:

x_{new} = x_{current} + (x_{current} - x_{previous}) + a \Delta t^2

Where:
$x_{current}$ → current position

$x_{previous}$ → previous position

$a$ → acceleration (gravity, wind etc.)

Representing Cloth as a Grid

A cloth can be represented as a grid of particles connected by constraints.

Each particle stores:

Current position
Previous position

Neighbouring particles are connected by distance constraints that maintain the cloth structure.

o---o---o---o
| | | |
o---o---o---o
| | | |
o---o---o---o

Some particles are pinned so the cloth does not fall entirely.

The Julia Implementation

Below is the Julia program that simulates the cloth.

using LinearAlgebra
using Plots

nx = 25
ny = 20
spacing = 0.2
dt = 0.02
steps = 300
gravity = [0.0,-9.8]

# Create grid
pos = [ [i*spacing, j*spacing] for j in 1:ny, i in 1:nx ]
prev = deepcopy(pos)

# Pin top row
pinned = [(i,ny) for i in 1:nx]

constraints = []

for j in 1:ny
    for i in 1:nx
        if i < nx
            push!(constraints, ((i,j),(i+1,j)))
        end
        if j < ny
            push!(constraints, ((i,j),(i,j+1)))
        end
    end
end

function verlet_step(step)

    wind = [2*sin(0.05*step),0.0]

    for j in 1:ny
        for i in 1:nx

            if (i,j) in pinned
                continue
            end

            temp = pos[j,i]

            accel = gravity + wind

            pos[j,i] = pos[j,i] + (pos[j,i]-prev[j,i]) + accel*dt^2

            prev[j,i] = temp
        end
    end
end

function satisfy_constraints()

    for ((i1,j1),(i2,j2)) in constraints

        p1 = pos[j1,i1]
        p2 = pos[j2,i2]

        delta = p2 - p1
        dist = norm(delta)

        rest = spacing
        diff = (dist-rest)/dist

        if !((i1,j1) in pinned)
            pos[j1,i1] += delta*0.5*diff
        end

        if !((i2,j2) in pinned)
            pos[j2,i2] -= delta*0.5*diff
        end
    end
end

anim = @animate for step in 1:steps

    verlet_step(step)

    for k in 1:6
        satisfy_constraints()
    end

    x = [pos[j,i][1] for j in 1:ny, i in 1:nx]
    y = [pos[j,i][2] for j in 1:ny, i in 1:nx]

    scatter(x,y,legend=false,xlim=(0,6),ylim=(-5,6),markersize=3)
end

gif(anim,"cloth.gif",fps=30)

A sinusoidal wind creates cloth fluttering.

What the Simulation Does

The simulation includes:

Gravity

gravity = [0.0,-9.8]
Every particle experiences downward acceleration.

Wind Force

wind = [2*sin(0.05*step),0.0]
A sinusoidal wind creates cloth fluttering.

Constraint Relaxation

Multiple iterations enforce distance constraints so the cloth maintains its shape.

for k in 1:6
    satisfy_constraints()
end

This technique is commonly used in Position Based Dynamics.

Visual Result

The script generates an animated GIF showing a cloth hanging from the top row while wind and gravity deform it dynamically.

Even with a few dozen lines of code, we get a convincing physical effect.

What Makes Julia Interesting for Graphics Simulation

Working with Julia gives several advantages:
• Fast numerical computation

• Simple array operations

• Easy prototyping for physics simulations

• Smooth transition from mathematics to implementation

This makes it attractive for engineers exploring scientific computing , graphics , and simulation together.

A Personal Reflection

This small experiment reminded me of the moment I watched my son exploring cloth simulation in Blender years ago.

Back then, he was experimenting visually.

Today I tried to rebuild the physics underneath that visual tool.

Sometimes inspiration in engineering does not come from textbooks — it comes from watching curiosity in the next generation.

And that curiosity often pushes us to explore deeper layers of science and software.