Can a deadlock occur on commit?

To fix this issue By the information you give - no, a deadlock can't occur:
First, you don't mention multiple threads. A single thread can't cause a deadlock. But let's assume you have multiple threads.

it helps some times No, that won't deadlock:
once the producer can get the lock, it releases it promptly (the pulse doesn't interrupt the producer) once the consumer can get the lock, it either finds data, or it waits (releasing the lock) appropriately

it should still fix some issue Deadlocks occur when two processes block each other by trying to obtain the same resources in a different order. I've seen Oracle deadlocks happen for three reasons, there are probably more:
Concurrent sessions update the same rows in different order because explain plans retrieve the rows differently. For example, one session uses an index and another uses a full table scan. Un-indexed foreign keys cause table locks. Bitmap indexes and any type of concurrent DML on a table.

create table position(name varchar2(100), extra varchar2(4000), bonus number);

insert into position select 'JOHN', null, 1 from dual connect by level <= 100;
insert into position select level , null, 1 from dual connect by level <= 100000;

create index position_index on position(name);

begin
    for i in 1 .. 1000 loop
        UPDATE POSITION SET EXTRA = EXTRA || 'yes' WHERE NAME='JOHN';
        commit;
    end loop;
end;
/

begin
    for i in 1 .. 1000 loop
        UPDATE POSITION SET BONUS = BONUS * 1.05;
        commit;
    end loop;
end;
/

ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
ORA-06512: at line 3

select value from v$parameter where name like 'background_dump_dest';

...

Deadlock graph:
                                          ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name                             process session holds waits  process session holds waits
TX-0009000F-00004ACC-00000000-00000000         37     129     X             55     375           X
TX-0008001B-0000489C-00000000-00000000         55     375     X             37     129           X

session 129: DID 0001-0025-00000281 session 375: DID 0001-0037-00012A2C 
session 375: DID 0001-0037-00012A2C session 129: DID 0001-0025-00000281 

Rows waited on:
  Session 129: obj - rowid = 0001AC1C - AAAawcAAGAAAudMAAQ
  (dictionary objn - 109596, file - 6, block - 190284, slot - 16)
  Session 375: obj - rowid = 0001AC1C - AAAawcAAGAAAudMAAL
  (dictionary objn - 109596, file - 6, block - 190284, slot - 11)

----- Information for the OTHER waiting sessions -----
Session 375:
  sid: 375 ser: 10033 audsid: 56764801 user: 111/xxxxxxxxxxxx
    flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
  pid: 55 O/S info: user: oracle, term: xxxxxxxxxx, ospid: 7820
    image: ORACLE.EXE (SHAD)
  client details:
    O/S info: user: xxxxxxxxxx\xxxxxxxxxx, term: xxxxxxxxxx, ospid: 11848:10888
    machine: xxxxxxxxxx\xxxxxxxxxx program: sqlplus.exe
    application name: SQL*Plus, hash value=3669949024
  current SQL:
  UPDATE POSITION SET BONUS = BONUS * 1.05

----- End of information for the OTHER waiting sessions -----

Information for THIS session:

----- Current SQL Statement for this session (sql_id=cp515bpfsjd07) -----
UPDATE POSITION SET EXTRA = EXTRA || 'yes' WHERE NAME='JOHN'

...

select * from dba_objects where object_id = 109596;

it helps some times What is happening is that std::condition_variable::wait is releasing the mutex. The thread then waits until the notify_one call, that will release the condition and re-acquire the mutex.
http://en.cppreference.com/w/cpp/thread/condition_variable/wait