Modern software systems often separate control logic from high-performance execution logic. This design is common in networking, distributed systems, operating systems, storage engines, and embedded software.
In this project, we build a simple Linux application that demonstrates this architectural pattern using:
- F# as the Control Plane
- C as the Data Plane
- P/Invoke for interoperability
- Linux Shared Libraries (.so)
Although the example is intentionally simple, the same design scales to much larger systems.
Why Separate Control Plane and Data Plane?
Different programming languages excel at different tasks.
| Control Plane |
Data Plane |
| User interaction |
High-performance computation |
| Input validation |
Native execution |
| Business logic |
Memory-efficient processing |
| Workflow orchestration |
Optimized algorithms |
| F# |
C |
In this project:
- F# collects user input.
- The terrain data is stored in a managed array.
- The array is passed directly to native C.
- C prints the terrain grid.
This demonstrates a clean separation of responsibilities.
Project Architecture
The project consists of two independent components.
Control Plane
Responsibilities:
- Read terrain dimensions
- Read elevation values
- Store data in a managed array
- Invoke native code
Technology:
Data Plane
Responsibilities:
- Receive terrain data
- Traverse the array
- Print formatted output
Technology:
- C
- GCC
- Shared Library (.so)
Project Structure
terrain_grid/
│
├── control_plane/
│ ├── Program.fs
│ ├── Terrain.fs
│ └── control_plane.fsproj
│
├── data_plane/
│ ├── terrain.c
│ ├── terrain.h
│ └── libterrain.so
│
└── README.md
The Control Plane (F#)
The control plane is responsible for gathering input and forwarding it to the native library.
A simplified version:
let terrain = Array.zeroCreate<double>(rows * cols)
Terrain.display_terrain(
terrain,
rows,
cols)
Notice that the F# code never performs the display itself.
Its only responsibility is orchestration.
Calling Native C with P/Invoke
The bridge between managed and native code is created with DllImport.
[<DllImport("libterrain.so",
CallingConvention = CallingConvention.Cdecl)>]
extern void display_terrain(
double[] terrain,
int rows,
int cols)
P/Invoke automatically marshals the managed array into a native pointer that the C library can consume.
The Data Plane (C)
The C library receives a pointer to the terrain array and prints the values.
void display_terrain(
const double* terrain,
int rows,
int cols)
{
printf("%8.2f",
terrain[i * cols + j]);
}
Because the array is stored contiguously, indexing is straightforward.
Why Use a One-Dimensional Array?
Although the terrain logically represents a matrix, it is stored as a linear array.
Advantages include:
- Contiguous memory
- Better cache locality
- Easier interoperability
- Simpler pointer arithmetic
- Lower overhead
The index calculation is:
index = row * columns + column
This technique is widely used in:
- Scientific computing
- Image processing
- Game engines
- Embedded software
- Numerical libraries
Building the Shared Library
Compile the native library using GCC.
gcc -shared -fPIC terrain.c -o libterrain.so
Building the F# Project
dotnet build
Run:
dotnet run
Sample Output
Rows : 2
Cols : 2
Elevation [0][0] : 2
Elevation [0][1] : 3
Elevation [1][0] : 4
Elevation [1][1] : 5
Terrain Grid (Elevation in meters)
----------------------------------
2.00 3.00
4.00 5.00
What This Example Demonstrates
This small application introduces several important concepts.
- F# to C interoperability
- Linux shared libraries
- P/Invoke
- Managed and native memory interaction
- Control Plane / Data Plane architecture
- One-dimensional representation of matrices
Where This Pattern Is Used
The same architecture appears in many production systems.
- Network packet processing
- Linux networking subsystems
- Storage engines
- Embedded firmware
- Robotics
- High-performance computing
- Scientific simulations
- CAD applications
- GIS software
- Image processing pipelines
The complexity may increase, but the architectural principle remains the same.
Possible Extensions
This project can easily be expanded by adding features such as:
- Terrain statistics
- Height normalization
- Gradient calculation
- Heat map generation
- Terrain smoothing
- File import/export
- CSV support
- Binary terrain format
- OpenGL visualization
- GIS integration
Conclusion
This project demonstrates how managed and native languages can work together effectively.
F# provides expressive and concise application logic, while C delivers predictable native execution. By combining the two through P/Invoke, developers can build applications that are both productive and performant.
Although the terrain grid application is intentionally small, it illustrates a design pattern that scales to much larger systems in systems programming, embedded development, and high-performance computing.
GitHub Repository
terrain_grid
https://github.com/aj333git/Civil_Mech_apps/tree/main/terrain_grid
