InnoDB Concurrent writes being ignored
"Don't queue it, just do it".  -- This is my advice on using queuing mechanisms in MySQL.  The effort to enqueue and dequeue small tasks is often more than simply doing the task.  However there are exceptions...

Is this a correct understanding of your "queue"?  You have exactly 70 tasks and they need to be done at times based on various external criteria.  That is, it is not really a typical queue, which can be thought of as "first in, first out".  However, sometimes you may have several of the 70 ready to go, but not enough resources to do all at once. ??

In that case, let's call it a "task status" table.  Dozens of updates per second feed status into the table.  Worker(s) issue a SELECT to see what to do now.  If the computation is too complex to do in a WHERE...ORDER BY...LIMIT 1, then simply readk all 70 and make the decision in a 'real' programming language.  (Yes, I have implemented such.)  Keep in mind that the focus of a database table is to hold raw data.  If you can process the data in a SELECT, that is just a bonus.

"Transactions"...  Keep in mind that transactions in InnoDB are not really designed to last more than a few seconds.  So, if the tasks take longer than that, you need to 'assign' a task to a 'worker'.  Better yet, have the 'worker' assign the task to itself.  Here's one efficient way:

-- with autocommit=1; that is, no need for transactional semantics
UPDATE tasks
    SET worker = $me
    WHERE worker IS NULL
    ORDER BY ...
    LIMIT 1;
if Rows_affected() &gt; 0, then I got a task, else none to get.
SELECT task_id FROM tasks
    WHERE worker = $me;   -- find out which task I got.


When finished:

UPDATE tasks
    SET worker = NULL
    WHERE worker = $me;


Beneficial:

INDEX(worker)


Sorry if I have rambled off in the wrong direction; perhaps there are useful clues anyway.