R: [AD] Mini-synchronization API proposal for 4.1.x

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> - should we use a BITMAP-style API:

Please do; this ensures API consistency.

As we're talking about synchronization, I'll push things more,
discussing what will probably be part only of future Allegro 5.
I'm not aware if any previous discussions were made on a threading API,
so if this has already been addressed, please point me to the messages
(is there a mailing lists archive online?).

Currently Allegro messes up a lot with timers/threads. The distinction
between them is not even coupled in the lib, so on some OS a timer is
setup as an ISR, while on other OSes timers are handled via a thread,
and the average user doesn't know whatever his timer really is. Correct
me if I'm wrong but the small synchronization API suggested here is
conceived to expose the user to the fact a timer routine can actually
run in a thread, with all the consequences that this fact brings in.
So to avoid the problem of "hidden" threading, I'm proposing to add also
an AL_THREAD type (Allegro 5 territory?) with a dedicated API to handle
OS indipendent threading (al_create_thread, al_resume_thread, etc.), and
to differentiate more interrupt timers from thread timers. Actually we
could cover both them explicitely, so the user can freely choose one of
them depending on his needs (assuming the choosen one is available on
the target platform).

Threads and mutexes could be set up into a vtable, whose pointer is
attached to the system vtable (we could put all proper hooks directly
into the system vtable, but that is already huge so IMO it's better a
separated one); something like:

typedef struct AL_CONCURRENCY_VTABLE {
	AL_THREAD (*create_thread)(void *, int priority);
	void (*destroy_thread)(AL_THREAD *thread);
	int (*resume_thread)(AL_THREAD *thread);
	int (*pause_thread)(AL_THREAD *thread);
	void (*wait_for_thread)(AL_THREAD *thread);
	...
	AL_MUTEX (*create_mutex)(int locked);
	int (*lock_mutex)(AL_MUTEX *mutex);
	int (*unlock_mutex)(AL_MUTEX *mutex);
	void (*destroy_mutex)(AL_MUTEX *mutex);
	...
} AL_CONCURRENCY_VTABLE;

IMHO exposing the difference between ISRs and threads is a desiderable
goal, as it forces the user to make distinction between them, thus
creating proper programs that run as they are supposed to run (no
unexpected race conditions from a program made by an user ignoring
Allegro is using a thread somewhere for example).

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/