2009-11-30 16:55:03 +01:00
|
|
|
#ifndef SQL_PLIST_H
|
|
|
|
#define SQL_PLIST_H
|
|
|
|
/* Copyright (C) 2008 MySQL AB
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; version 2 of the License.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
|
|
|
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
|
|
|
|
|
|
|
|
|
|
|
|
#include <my_global.h>
|
|
|
|
|
2010-01-21 21:43:03 +01:00
|
|
|
template <typename T, typename B, typename C> class I_P_List_iterator;
|
|
|
|
class I_P_List_null_counter;
|
2009-11-30 16:55:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Intrusive parameterized list.
|
|
|
|
|
|
|
|
Unlike I_List does not require its elements to be descendant of ilink
|
|
|
|
class and therefore allows them to participate in several such lists
|
|
|
|
simultaneously.
|
|
|
|
|
|
|
|
Unlike List is doubly-linked list and thus supports efficient deletion
|
|
|
|
of element without iterator.
|
|
|
|
|
|
|
|
@param T Type of elements which will belong to list.
|
|
|
|
@param B Class which via its methods specifies which members
|
|
|
|
of T should be used for participating in this list.
|
|
|
|
Here is typical layout of such class:
|
|
|
|
|
|
|
|
struct B
|
|
|
|
{
|
|
|
|
static inline T **next_ptr(T *el)
|
|
|
|
{
|
|
|
|
return &el->next;
|
|
|
|
}
|
|
|
|
static inline T ***prev_ptr(T *el)
|
|
|
|
{
|
|
|
|
return &el->prev;
|
|
|
|
}
|
|
|
|
};
|
2010-01-21 21:43:03 +01:00
|
|
|
@param C Policy class specifying how counting of elements in the list
|
|
|
|
should be done. Instance of this class is also used as a place
|
|
|
|
where information about number of list elements is stored.
|
|
|
|
@sa I_P_List_null_counter, I_P_List_counter
|
2009-11-30 16:55:03 +01:00
|
|
|
*/
|
|
|
|
|
2010-01-21 21:43:03 +01:00
|
|
|
template <typename T, typename B, typename C = I_P_List_null_counter>
|
|
|
|
class I_P_List : public C
|
2009-11-30 16:55:03 +01:00
|
|
|
{
|
|
|
|
T *first;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Do not prohibit copying of I_P_List object to simplify their usage in
|
|
|
|
backup/restore scenarios. Note that performing any operations on such
|
|
|
|
is a bad idea.
|
|
|
|
*/
|
|
|
|
public:
|
|
|
|
I_P_List() : first(NULL) { };
|
2010-01-21 21:43:03 +01:00
|
|
|
inline void empty() { first= NULL; C::reset(); }
|
2009-11-30 20:11:32 +01:00
|
|
|
inline bool is_empty() const { return (first == NULL); }
|
2009-11-30 16:55:03 +01:00
|
|
|
inline void push_front(T* a)
|
|
|
|
{
|
|
|
|
*B::next_ptr(a)= first;
|
|
|
|
if (first)
|
|
|
|
*B::prev_ptr(first)= B::next_ptr(a);
|
|
|
|
first= a;
|
|
|
|
*B::prev_ptr(a)= &first;
|
2010-01-21 21:43:03 +01:00
|
|
|
C::inc();
|
2009-11-30 16:55:03 +01:00
|
|
|
}
|
A prerequisite patch for the fix for Bug#46224
"HANDLER statements within a transaction might lead to deadlocks".
Introduce a notion of a sentinel to MDL_context. A sentinel
is a ticket that separates all tickets in the context into two
groups: before and after it. Currently we can have (and need) only
one designated sentinel -- it separates all locks taken by LOCK
TABLE or HANDLER statement, which must survive COMMIT and ROLLBACK
and all other locks, which must be released at COMMIT or ROLLBACK.
The tricky part is maintaining the sentinel up to date when
someone release its corresponding ticket. This can happen, e.g.
if someone issues DROP TABLE under LOCK TABLES (generally,
see all calls to release_all_locks_for_name()).
MDL_context::release_ticket() is modified to take care of it.
******
A fix and a test case for Bug#46224 "HANDLER statements within a
transaction might lead to deadlocks".
An attempt to mix HANDLER SQL statements, which are transaction-
agnostic, an open multi-statement transaction,
and DDL against the involved tables (in a concurrent connection)
could lead to a deadlock. The deadlock would occur when
HANDLER OPEN or HANDLER READ would have to wait on a conflicting
metadata lock. If the connection that issued HANDLER statement
also had other metadata locks (say, acquired in scope of a
transaction), a classical deadlock situation of mutual wait
could occur.
Incompatible change: entering LOCK TABLES mode automatically
closes all open HANDLERs in the current connection.
Incompatible change: previously an attempt to wait on a lock
in a connection that has an open HANDLER statement could wait
indefinitely/deadlock. After this patch, an error ER_LOCK_DEADLOCK
is produced.
The idea of the fix is to merge thd->handler_mdl_context
with the main mdl_context of the connection, used for transactional
locks. This makes deadlock detection possible, since all waits
with locks are "visible" and available to analysis in a single
MDL context of the connection.
Since HANDLER locks and transactional locks have a different life
cycle -- HANDLERs are explicitly open and closed, and so
are HANDLER locks, explicitly acquired and released, whereas
transactional locks "accumulate" till the end of a transaction
and are released only with COMMIT, ROLLBACK and ROLLBACK TO SAVEPOINT,
a concept of "sentinel" was introduced to MDL_context.
All locks, HANDLER and others, reside in the same linked list.
However, a selected element of the list separates locks with
different life cycle. HANDLER locks always reside at the
end of the list, after the sentinel. Transactional locks are
prepended to the beginning of the list, before the sentinel.
Thus, ROLLBACK, COMMIT or ROLLBACK TO SAVEPOINT, only
release those locks that reside before the sentinel. HANDLER locks
must be released explicitly as part of HANDLER CLOSE statement,
or an implicit close.
The same approach with sentinel
is also employed for LOCK TABLES locks. Since HANDLER and LOCK TABLES
statement has never worked together, the implementation is
made simple and only maintains one sentinel, which is used either
for HANDLER locks, or for LOCK TABLES locks.
2009-12-22 17:09:15 +01:00
|
|
|
inline void push_back(T *a)
|
|
|
|
{
|
|
|
|
insert_after(back(), a);
|
|
|
|
}
|
|
|
|
inline T *back()
|
|
|
|
{
|
|
|
|
T *t= front();
|
|
|
|
if (t)
|
|
|
|
{
|
|
|
|
while (*B::next_ptr(t))
|
|
|
|
t= *B::next_ptr(t);
|
|
|
|
}
|
|
|
|
return t;
|
|
|
|
}
|
|
|
|
inline void insert_after(T *pos, T *a)
|
|
|
|
{
|
|
|
|
if (pos == NULL)
|
|
|
|
push_front(a);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
*B::next_ptr(a)= *B::next_ptr(pos);
|
|
|
|
*B::prev_ptr(a)= B::next_ptr(pos);
|
|
|
|
*B::next_ptr(pos)= a;
|
|
|
|
if (*B::next_ptr(a))
|
|
|
|
{
|
|
|
|
T *old_next= *B::next_ptr(a);
|
|
|
|
*B::prev_ptr(old_next)= B::next_ptr(a);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-11-30 16:55:03 +01:00
|
|
|
inline void remove(T *a)
|
|
|
|
{
|
|
|
|
T *next= *B::next_ptr(a);
|
|
|
|
if (next)
|
|
|
|
*B::prev_ptr(next)= *B::prev_ptr(a);
|
|
|
|
**B::prev_ptr(a)= next;
|
2010-01-21 21:43:03 +01:00
|
|
|
C::dec();
|
2009-11-30 16:55:03 +01:00
|
|
|
}
|
A prerequisite patch for the fix for Bug#46224
"HANDLER statements within a transaction might lead to deadlocks".
Introduce a notion of a sentinel to MDL_context. A sentinel
is a ticket that separates all tickets in the context into two
groups: before and after it. Currently we can have (and need) only
one designated sentinel -- it separates all locks taken by LOCK
TABLE or HANDLER statement, which must survive COMMIT and ROLLBACK
and all other locks, which must be released at COMMIT or ROLLBACK.
The tricky part is maintaining the sentinel up to date when
someone release its corresponding ticket. This can happen, e.g.
if someone issues DROP TABLE under LOCK TABLES (generally,
see all calls to release_all_locks_for_name()).
MDL_context::release_ticket() is modified to take care of it.
******
A fix and a test case for Bug#46224 "HANDLER statements within a
transaction might lead to deadlocks".
An attempt to mix HANDLER SQL statements, which are transaction-
agnostic, an open multi-statement transaction,
and DDL against the involved tables (in a concurrent connection)
could lead to a deadlock. The deadlock would occur when
HANDLER OPEN or HANDLER READ would have to wait on a conflicting
metadata lock. If the connection that issued HANDLER statement
also had other metadata locks (say, acquired in scope of a
transaction), a classical deadlock situation of mutual wait
could occur.
Incompatible change: entering LOCK TABLES mode automatically
closes all open HANDLERs in the current connection.
Incompatible change: previously an attempt to wait on a lock
in a connection that has an open HANDLER statement could wait
indefinitely/deadlock. After this patch, an error ER_LOCK_DEADLOCK
is produced.
The idea of the fix is to merge thd->handler_mdl_context
with the main mdl_context of the connection, used for transactional
locks. This makes deadlock detection possible, since all waits
with locks are "visible" and available to analysis in a single
MDL context of the connection.
Since HANDLER locks and transactional locks have a different life
cycle -- HANDLERs are explicitly open and closed, and so
are HANDLER locks, explicitly acquired and released, whereas
transactional locks "accumulate" till the end of a transaction
and are released only with COMMIT, ROLLBACK and ROLLBACK TO SAVEPOINT,
a concept of "sentinel" was introduced to MDL_context.
All locks, HANDLER and others, reside in the same linked list.
However, a selected element of the list separates locks with
different life cycle. HANDLER locks always reside at the
end of the list, after the sentinel. Transactional locks are
prepended to the beginning of the list, before the sentinel.
Thus, ROLLBACK, COMMIT or ROLLBACK TO SAVEPOINT, only
release those locks that reside before the sentinel. HANDLER locks
must be released explicitly as part of HANDLER CLOSE statement,
or an implicit close.
The same approach with sentinel
is also employed for LOCK TABLES locks. Since HANDLER and LOCK TABLES
statement has never worked together, the implementation is
made simple and only maintains one sentinel, which is used either
for HANDLER locks, or for LOCK TABLES locks.
2009-12-22 17:09:15 +01:00
|
|
|
inline T* front() { return first; }
|
|
|
|
inline const T *front() const { return first; }
|
2010-01-21 21:43:03 +01:00
|
|
|
void swap(I_P_List<T, B, C> &rhs)
|
2009-11-30 16:55:03 +01:00
|
|
|
{
|
|
|
|
swap_variables(T *, first, rhs.first);
|
|
|
|
if (first)
|
|
|
|
*B::prev_ptr(first)= &first;
|
|
|
|
if (rhs.first)
|
|
|
|
*B::prev_ptr(rhs.first)= &rhs.first;
|
2010-01-21 21:43:03 +01:00
|
|
|
C::swap(rhs);
|
2009-11-30 16:55:03 +01:00
|
|
|
}
|
|
|
|
#ifndef _lint
|
2010-01-21 21:43:03 +01:00
|
|
|
friend class I_P_List_iterator<T, B, C>;
|
2009-11-30 16:55:03 +01:00
|
|
|
#endif
|
2010-01-21 21:43:03 +01:00
|
|
|
typedef I_P_List_iterator<T, B, C> Iterator;
|
2009-11-30 16:55:03 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Iterator for I_P_List.
|
|
|
|
*/
|
|
|
|
|
2010-01-21 21:43:03 +01:00
|
|
|
template <typename T, typename B, typename C = I_P_List_null_counter>
|
2009-11-30 16:55:03 +01:00
|
|
|
class I_P_List_iterator
|
|
|
|
{
|
2010-01-21 21:43:03 +01:00
|
|
|
const I_P_List<T, B, C> *list;
|
2009-11-30 16:55:03 +01:00
|
|
|
T *current;
|
|
|
|
public:
|
2010-01-21 21:43:03 +01:00
|
|
|
I_P_List_iterator(const I_P_List<T, B, C> &a) : list(&a), current(a.first) {}
|
|
|
|
I_P_List_iterator(const I_P_List<T, B, C> &a, T* current_arg) : list(&a), current(current_arg) {}
|
|
|
|
inline void init(const I_P_List<T, B, C> &a)
|
2009-11-30 16:55:03 +01:00
|
|
|
{
|
|
|
|
list= &a;
|
|
|
|
current= a.first;
|
|
|
|
}
|
|
|
|
inline T* operator++(int)
|
|
|
|
{
|
|
|
|
T *result= current;
|
|
|
|
if (result)
|
|
|
|
current= *B::next_ptr(current);
|
|
|
|
return result;
|
|
|
|
}
|
A prerequisite patch for the fix for Bug#46224
"HANDLER statements within a transaction might lead to deadlocks".
Introduce a notion of a sentinel to MDL_context. A sentinel
is a ticket that separates all tickets in the context into two
groups: before and after it. Currently we can have (and need) only
one designated sentinel -- it separates all locks taken by LOCK
TABLE or HANDLER statement, which must survive COMMIT and ROLLBACK
and all other locks, which must be released at COMMIT or ROLLBACK.
The tricky part is maintaining the sentinel up to date when
someone release its corresponding ticket. This can happen, e.g.
if someone issues DROP TABLE under LOCK TABLES (generally,
see all calls to release_all_locks_for_name()).
MDL_context::release_ticket() is modified to take care of it.
******
A fix and a test case for Bug#46224 "HANDLER statements within a
transaction might lead to deadlocks".
An attempt to mix HANDLER SQL statements, which are transaction-
agnostic, an open multi-statement transaction,
and DDL against the involved tables (in a concurrent connection)
could lead to a deadlock. The deadlock would occur when
HANDLER OPEN or HANDLER READ would have to wait on a conflicting
metadata lock. If the connection that issued HANDLER statement
also had other metadata locks (say, acquired in scope of a
transaction), a classical deadlock situation of mutual wait
could occur.
Incompatible change: entering LOCK TABLES mode automatically
closes all open HANDLERs in the current connection.
Incompatible change: previously an attempt to wait on a lock
in a connection that has an open HANDLER statement could wait
indefinitely/deadlock. After this patch, an error ER_LOCK_DEADLOCK
is produced.
The idea of the fix is to merge thd->handler_mdl_context
with the main mdl_context of the connection, used for transactional
locks. This makes deadlock detection possible, since all waits
with locks are "visible" and available to analysis in a single
MDL context of the connection.
Since HANDLER locks and transactional locks have a different life
cycle -- HANDLERs are explicitly open and closed, and so
are HANDLER locks, explicitly acquired and released, whereas
transactional locks "accumulate" till the end of a transaction
and are released only with COMMIT, ROLLBACK and ROLLBACK TO SAVEPOINT,
a concept of "sentinel" was introduced to MDL_context.
All locks, HANDLER and others, reside in the same linked list.
However, a selected element of the list separates locks with
different life cycle. HANDLER locks always reside at the
end of the list, after the sentinel. Transactional locks are
prepended to the beginning of the list, before the sentinel.
Thus, ROLLBACK, COMMIT or ROLLBACK TO SAVEPOINT, only
release those locks that reside before the sentinel. HANDLER locks
must be released explicitly as part of HANDLER CLOSE statement,
or an implicit close.
The same approach with sentinel
is also employed for LOCK TABLES locks. Since HANDLER and LOCK TABLES
statement has never worked together, the implementation is
made simple and only maintains one sentinel, which is used either
for HANDLER locks, or for LOCK TABLES locks.
2009-12-22 17:09:15 +01:00
|
|
|
inline T* operator++()
|
|
|
|
{
|
|
|
|
current= *B::next_ptr(current);
|
|
|
|
return current;
|
|
|
|
}
|
2009-11-30 16:55:03 +01:00
|
|
|
inline void rewind()
|
|
|
|
{
|
|
|
|
current= list->first;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2010-01-21 21:43:03 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
Element counting policy class for I_P_List to be used in
|
|
|
|
cases when no element counting should be done.
|
|
|
|
*/
|
|
|
|
|
|
|
|
class I_P_List_null_counter
|
|
|
|
{
|
|
|
|
protected:
|
|
|
|
void reset() {}
|
|
|
|
void inc() {}
|
|
|
|
void dec() {}
|
|
|
|
void swap(I_P_List_null_counter &rhs) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Element counting policy class for I_P_List which provides
|
|
|
|
basic element counting.
|
|
|
|
*/
|
|
|
|
|
|
|
|
class I_P_List_counter
|
|
|
|
{
|
|
|
|
uint m_counter;
|
|
|
|
protected:
|
|
|
|
I_P_List_counter() : m_counter (0) {}
|
|
|
|
void reset() {m_counter= 0;}
|
|
|
|
void inc() {m_counter++;}
|
|
|
|
void dec() {m_counter--;}
|
|
|
|
void swap(I_P_List_counter &rhs)
|
|
|
|
{ swap_variables(uint, m_counter, rhs.m_counter); }
|
|
|
|
public:
|
|
|
|
uint elements() const { return m_counter; }
|
|
|
|
};
|
|
|
|
|
2009-11-30 16:55:03 +01:00
|
|
|
#endif
|