A cousin to TableOrientedProgramming. TOP uses relational tables for method dispatch; TOS uses 'em for synchronization, mutual exclusion, and inter-process communication. Formal programming-language "threads" are not needed because each thread/fork/instance talks to the database (server-side or client-side) in client-server-like fashion to communicate with other processes. {Note that TopMind did NOT create this topic.} Essentially, TableOrientedSynchronization (which is being proposed as a bit of a StrawMan) is the use of a RelationalDatabase (actually, any database will do but relational ones are preferred on general principle) as the sole means for addressing the above concerns--even (especially?) if no persistent business data is involved. Extra points if done for sync/mutex/IPC among threads within a single process (a NimbleDatabase can be used in this case). Need a classic semaphore? It's just a simple table with a single record containing a single attribute--the semaphore's value. The database will ensure that modifications of the semaphore's value are done atomically (though you're on your own if you want to block rather than poll the thing--triggers can help...) Need a message queue? Just make a table containing your packets, and an additional column containing some unique ID--it's well known that tables can simulate queues. Construction of mutexes, monitors, reader/writer semaphores, pipes, files, CommunicatingSequentialProcesses, and numerous other primitives for synchronization/mutual exclusion/inter-process communication is left as an exercise for the reader. (I'm sure someone will demonstrate that select() can be implemented as a relational join in such a scheme). It may be an AbstractionInversion from hell, but who cares? Programmers shouldn't have to deal with lots of different types of primitives for this sort of stuff--outside of EwDijkstra, TonyHoare, and the guys who write RDBMS engines, nobody can figure this stuff out anyway. And who knows? There may be some scenario which the low-level primitives ''just can't handle'' the complex synchronization logic, and being able to do AdHocQueries on the fullness of a semaphore may be the only solution. ----- '''Kinds of Table Oriented Concurrency Management''' * Locks ** Row locks ** Table locks * ACID ** Full ACID (AtomicConsistentIsolatedDurable) ** ACI (AtomicConsistentIsolated) There are different approaches to TableOrientedSynchronization. A more primitive type is row and table locks. Although these can help with multi-language concurrency issues, they are still subject to problems of rogue processes locking out all other potential users of a given row or table. Some kind of maximum time-out threshold perhaps can be set, but some processes will be long by nature. ACI or ACID is a more sophisticated approach. There is no explicit "wait" step. Most BigIron RDBMS provide both types (locks and ACID). It may be argued that only ACID is needed, but it seems to suffer performance problems for certain kinds of bulk changes. Maybe ACID can logically work, but so far implementations have not been able to live up to the full ideal. -- top ---- Re: "even (especially?) if no persistent business data is involved." DatabasesAreMoreThanJustStorage. I would suggest they are also a good/fair candidate for any domain where tracking a lot of "stuff" is important. However, I will agree that RDBMS tend to be optimized for business applications from a vendor implementation standpoint. Thus, they are often slow in domains such as CADD and text indexing. ---- Re: ''It may be an AbstractionInversion from hell'' Could you elaborate? Databases are generally pretty well-tested and pretty reliable (at least compared to the alternatives). Maybe if you ''only'' use it for concurrency it may be overkill, but usually there are other database-ish things being done with the information anyhow. One can get lots of almost-free stuff hanging around a database, and its all integrated. For example, at first you may just use it to keep two people from doing the same thing at the same time. But later you may want a log of the activity. Rather than delete records you can just change the code a bit to use a status flag and add a time-stamp, and ''voilà'': a logger. No code overhauls, just incremental changes. ---- After several years of holding off, I can refrain no longer: CategoryWikiFavorites. ThankYou to whoever created this page. ----- How does this work with the '''GUI''' engine? Suppose you want the GUI to be handling multiple requests such as when typing to a text-area and updating a search results data grid at the same time? I suppose a one could have the search process transfer the search results to a holding table (not visible to GUI yet), and then fill up the GUI grid when the grid gains focus. But what if we want the current search count or a progress bar of the search results updating while we are typing? I suppose it depends on the nature of the GUI engine. Perhaps process 2 could queue up a GUI request to update the progress bar while process 1 is handling the text input. In between handling user typing, it would process the request queue and update the progress bar/count. This may depend on whether the GUI engine is embedded in the application language or outside of it. I think a progress bar/message should be built-in to any GUI kit because it is a very common need. However, another fairly-common alternative for longer-running items is a "report queue" or "process queue". One can check the queues via a menu option to see the progress. This can be a regular database query, assuming the progress or queue info is stored in database tables. Generally, only "processing", "error", or "finished" are the available options. ---- CategoryConcurrency