Home/ Questions/Q 4234534
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T02:22:10+00:00

For academic purposes I’ve realized a C# library that implements computation with agents, thinking

  • 0

For academic purposes I’ve realized a C# library that implements “computation with agents”, thinking for example to what JADE does. With this library I can implement a distributed computation algorithm easily. Every agent is an object having a different thread implementing a part of the computation, while the object itself remains free to receive and dispatch messages.
These algorithms can run thousands agents (so threads), monitored by a super-agent that changes their status and synchronize them: I cannot create 10.000 threads and let them run all together, because PC could die…
So every agent has a changing status that I should draw on a GUI to let user realize what is happening during computation. And my agents can be created and killed during computation too, making it harder…
I thought to use a grid in which every cell is an agent, changing background color of every cell according to agent status, but I’m not sure how to “join” single agent to a cell (remember I cannot use an index, because agents number can change and some agent could be destroyed; I thought to create a Control for every new agent and place this Control in the GUI, so I can quickly create, place and destroy it when needed.
The big deal is the huge number of threads and the need to refresh GUI as quick as possible, because threads status change continuously and very quickly.
What can you suggest? What is the best way to accomplish my task?

UPDATE: I’m developing this library using Framework 2.0 because it MUST run under Linux too using Mono.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Have a central synchronized hashmap that maps thread id -> GUI element.
    In this way the super-agent can do changes to the GUI, create new threads and atomically update the hashmap (e.g. this allows reusing GUI elements for new threads). This will obviously cause some read contention on the hashmap when the super-agent gets a lock to update it.

    edit: actually you can even get rid of the hashmap and just have an array because the maximum number of threads you can have is quite low (< 2^16), I guess. This would also get rid of the contention, because you could lock single array elements instead of the whole hashmap.

    edit2: It actually just occurred to me that you can get rid of everything. Just have a shared surface of 256×256 pixels (i.e. 2^16 pixels). Each pixel belongs to the thread whose threadID is equal to the pixel index. This way each thread only accesses its own pixel. Then create a custom control and have the OnPaint method blit the shared surface to the graphic surface.

    • 0