Could you make a thread-safe API for multi-threading, How?

I have a hard time understanding coroutines, but I'd like to make a thread-safe multi-threading API for basically allowing you to do more than the parallel (API), it's an objected-oriented (API) that allows you to add tasks to the list, remove tasks from the list, run tasks in the list, stop tasks in the list, resume tasks in the list, pause tasks in the list and this would be in-order and thread-safe.

Add / Remove tasks, will add or remove tasks from the list, if a task is running and then removed it will stop and get removed.
Start / Stop tasks, starting tasks will stop if it's already running and start from the beginning, stopping tasks will just stop it.
Resume / Pause, tasks can be paused and then resumed to continue.

By thread-safe, I mean synchronized with every other task.

Could thread-safety be possible, if so then how? And how could I make such an API? Thanks, if you can explain your code that's be even better. If someone has such an API already, can they please showcase it here and explain it? Thanks again.

Regards,
Augustas

What on earth do you mean by "thread-safe" in the context of ComputerCraft Lua? What does "synchronized with every other task" entail, exactly? I think you may have some very basic misconceptions about the way coroutines work. Only one is ever running at any given point in time, there are never two things running at the same time in ComputerCraft Lua.

Lyqyd is right. It sounds like you're confusing Lua's coroutines (cooperative threads) with preemptive threads. In a cooperative threading context, there's no need for synchronization or worrying about thread safety. That all has to do with the possibility of two threads accessing the same memory at once, which is impossible with coroutines.

Now, to answer your query about a task-based system where you can add and remove coroutines, I'll explain a bit about how coroutines get resumed in ComputerCraft. Whenever you call os.pullEvent, you're actually yielding the currently running coroutine to whatever resumed it. If you're inside a parallel.waitFor* call, it's the event loop in the parallel API which resumes your static list of functions you give it, over and over again. If you're just in some main code, you're actually yielding to a parallel.waitForAny loop which gets started inside bios.lua. parallel.waitFor* implements an event loop which resumes the threads you give it with the event data it gets directly from the Java side of things, where presumably the main coroutine of the Lua state gets resumed over and over. Java resumes the parallel event loop with event data, the event loop resumes its coroutines with events if they meet the event filter, and it modifies its event filters by catching that data from the coroutines when they yield.

A system of adding and removing coroutines is just a matter of capturing the events in a loop, sending them to the coroutines building filters by capturing the filter data from the coroutines, and exposing functions for adding and removing coroutines from the coroutine table.

This isn't a new idea. It's been done quite a few times before. Gopher's goroutines and my SEE threads are what come to mind, but most likely tons of other identical systems have been created for use in OSes.

Okay thank you for the clarification.