Not very sure. These threads terminates really fast and the overhead is not so big.
Of course if it was possible to implement such behavior without threads - it would be better, but it is not possible.
At first, Linux support for signals does not allow (strictly) using of arbitrary code - you are limited to make some memory access and calling some "safe" libc functions. For example using dynamic memory allocations is not possible.
If we need universal timer - the code of the timer procedure must be executed outside the Linux signal handler.
Also, this code must be executed asynchronously towards main thread.
For Win32 the things seems to be easier (maybe because I still didn't try to implement them ) but I need an approach that will work on almost every OS.
Threads looks the only real opportunity.
If someone have better idea - I will be glad to rewrite the code, even entirely.

Sure I understand that inside the thread there would be very little code that needs to be run, but the OS has to create the thread with handles and context information, insert it in the scheduler list, allocate memory for stack space etc. Then switch to it to execute things at some point. And later release all the resources when the thread exits. If the timer expiries occur frequently and/or with small timeout delays then things start to get rather congested.

Perhaps a queue system would be better? You could dedicate one thread to dispatching from the queue as each timer expires. This also has the advantage of keeping everything in order (some programs rely upon this for correctness).

This looks like good solution. Thanks for the idea, I will try it.

I know that it's not exactly what you need for your homework, but once I wrote this little thread-example with timer (it's gas source not a fasm one).

Endre: Creating threads is not an issue. Although using rsi/edi for passing arguments to "clone" looks strange - is it x64 related, or some other system API (not Linux)?
Also, as revolution said - I can't assemble it.

It is done! I have working timer system for FreshLib now. It uses one additional thread and uses very little CPU. If someone is interested - the code is in the repository: timers/linux/timer.asm file in FreshLibDev branch.
As a side effect FreshLib have now Linux thread support in the file: system/Linux/process.asm

The implementation does not uses queue for the events, but counter in every timer that counts how many times the counter expired. Then the thread checks this counts and calls the callback for every expiration.

Thanks for the help.

The most recent news from my battle with the timers.
As it appeared, XLib have some really nasty behavior towards threads.
As a result I stuck with timers for many days... The test application crashed again and again with really weird messages (or without them). Using documented XInitThreads and XLockDisplay didn't help at all.
After trying my own lock that to guarantee non simultaneous calls of XLib functions and the program became nearly stable, I realized, that the problem is that XLib simply can't distinguish my threads ( created using sys_clone) and doesn't lock at all. It simply counts all threads as one.

After I changed ThreadCreate procedure to use pthreads library, all was fixed as in magic. Now the test application works for my computers (Win32 with andLinux and Ubuntu 10.10) really well.

Anyway, let's make some tests. Here I am attaching the compiled test program. Please run it on your Linux box and report if there are some problems.

The sources are on usual place in the repository.

Regards.